Web Inspector: Crash in InspectorDOMAgent::pushNodePathToFrontend when inspecting document with CSS generated content
https://bugs.webkit.org/show_bug.cgi?id=104780

Patch by Antoine Quint <graouts@apple.com> on 2012-12-12
Reviewed by Pavel Feldman.

Source/WebCore:

The pushNodePathForRenderLayerToFrontend() method added to InspectorDOMAgent naively assumed
that all RenderLayers have a Node associated to them. However, in the case of CSS generated
content, that will not be the case and we would call into pushNodePathToFrontend() with a 0
parameter that would hit the first ASSERT in this method. We're now checking that we indeed
have an associated node for the provided RenderLayer and return 0 in case we don't, without
calling into pushNodePathToFrontend().

Test: inspector-protocol/layer-tree-generated-content.html

* inspector/InspectorDOMAgent.cpp:
(WebCore::InspectorDOMAgent::pushNodePathForRenderLayerToFrontend):

LayoutTests:

Adding a new test for the LayerTreeAgent to check that it does not crash when inspecting
a page with CSS generated content, and correctly returns nodeId === 0 in the situation
where there is no Node associated with a given RenderLayer.

* inspector-protocol/layer-tree-generated-content-expected.txt: Added.
* inspector-protocol/layer-tree-generated-content.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137466 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL [WebGL] [Wk2] Resizing the canvas breaks WebGL.
https://bugs.webkit.org/show_bug.cgi?id=104535.

Patch by Kondapally Kalyan <kalyan.kondapally@intel.com> on 2012-12-12
Reviewed by Kenneth Rohde Christiansen.

GraphicsContext3DEfl does not re-create the surface on canvas resize, this
conflicted with the logic in coordinated graphics Layer.
CoordinatedGraphicsLayer checks for GraphicsSurfaceToken to decide if the surface
in UI-Process should be recreated or not. With this
patch we also check for size of the platform Layer.

Source/WebCore:

* platform/graphics/efl/GraphicsContext3DEfl.cpp:
(WebCore::GraphicsContext3D::createGraphicsSurfaces):
* platform/graphics/efl/GraphicsContext3DPrivate.cpp:
(GraphicsContext3DPrivate::didResizeCanvas):
(GraphicsContext3DPrivate::platformLayerSize):
* platform/graphics/efl/GraphicsContext3DPrivate.h:
(GraphicsContext3DPrivate):

Source/WebKit2:

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::setContentsToCanvas):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.h:
(CoordinatedGraphicsLayer):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137467 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Native Memory Instrumentation: remove fake root MemoryObjectInfo.
https://bugs.webkit.org/show_bug.cgi?id=104796

Reviewed by Yury Semikhatsky.

It was not a good idea to introduce a fake root MemoryObjectInfo.
It makes a problem when we visit an object without its own MemoryObjectType.

Example: RenderBox has a global pointer to a hash map.
HashMap doesn't have its own object type because it is a generic container.
It will inherit object type from the fake root memory object info.
The same could happen for another container in another class with other MemoryObjectType.

This fact forces me to create custom process method for root objects
because they need to have their own MemoryObjectInfo with customisable memory object type.

Source/JavaScriptCore:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

Source/WebCore:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

* inspector/MemoryInstrumentationImpl.cpp:
(WebCore::MemoryInstrumentationImpl::processDeferredObjects):
(WebCore::MemoryInstrumentationImpl::deferObject):
(WebCore::MemoryInstrumentationImpl::reportMemoryUsage):
* inspector/MemoryInstrumentationImpl.h:
(MemoryInstrumentationImpl):

Source/WTF:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

* wtf/MemoryInstrumentation.cpp:
(WTF::MemoryInstrumentation::MemoryInstrumentation):
(WTF::MemoryInstrumentation::WrapperBase::WrapperBase):
(WTF::MemoryInstrumentation::WrapperBase::process):
(WTF::MemoryInstrumentation::WrapperBase::processRootObjectRef):
(WTF):
* wtf/MemoryInstrumentation.h:
(WTF::MemoryInstrumentation::addRootObject):
(MemoryInstrumentation):
(WrapperBase):
(WTF::MemoryInstrumentation::WrapperBase::~WrapperBase):
(Wrapper):
(OwningTraits):
(WTF::MemoryInstrumentation::OwningTraits::addRootObject):
(WTF::MemoryInstrumentation::addObjectImpl):
(WTF::::Wrapper):
(WTF::::callReportMemoryUsage):

Tools:

* TestWebKitAPI/Tests/WTF/MemoryInstrumentationTest.cpp:

Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137468 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Add sections documentation to WebKit2 GTK+ API
https://bugs.webkit.org/show_bug.cgi?id=104484

Reviewed by Martin Robinson.

Many of the sections in the WebKit2 GTK+ API documentation were
missing. This commit adds new documentation, in some cases
adapting it from WebKitGtk+ and in others writing it from the
scratch.

It also removes the WebKitWebViewBase class from the documentation
index, since it is not really relevant.

* UIProcess/API/gtk/WebKitBackForwardListItem.cpp:
* UIProcess/API/gtk/WebKitContextMenu.cpp:
* UIProcess/API/gtk/WebKitContextMenuItem.cpp:
* UIProcess/API/gtk/WebKitCookieManager.cpp:
* UIProcess/API/gtk/WebKitDownload.cpp:
* UIProcess/API/gtk/WebKitError.cpp:
* UIProcess/API/gtk/WebKitFaviconDatabase.cpp:
* UIProcess/API/gtk/WebKitFindController.cpp:
* UIProcess/API/gtk/WebKitFormSubmissionRequest.cpp:
* UIProcess/API/gtk/WebKitPlugin.cpp:
* UIProcess/API/gtk/WebKitPrintOperation.cpp:
* UIProcess/API/gtk/WebKitSecurityManager.cpp:
* UIProcess/API/gtk/WebKitURIRequest.cpp:
* UIProcess/API/gtk/WebKitURIResponse.cpp:
* UIProcess/API/gtk/WebKitURISchemeRequest.cpp:
* UIProcess/API/gtk/WebKitVersion.cpp:
* UIProcess/API/gtk/WebKitWebContext.cpp:
* UIProcess/API/gtk/WebKitWebInspector.cpp:
* UIProcess/API/gtk/WebKitWebResource.cpp:
(webkit_web_resource_class_init):
* UIProcess/API/gtk/WebKitWebView.cpp:
* UIProcess/API/gtk/docs/webkit2gtk-docs.sgml:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137469 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix slow test so it passes consistently now that we have multipart support
in soup.

Reviewed by Martin Robinson.

The multipart-wait-before-boundary test waits for 30 seconds before
sending the boundary. That is a bit long in itself, but it is exactly
the timeout used for slow tests in some platforms. This change reduces
the wait to 20 seconds, which should be enough for the test, and marks
the test as slow for GTK+.

* http/tests/multipart/resources/multipart-wait-before-boundary.php: wait
for 20 seconds instead of 30, before sending the boundary.
* platform/gtk/TestExpectations: mark test above as slow.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137470 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, GTK gardening. Flag some flaky media tests after r137271.

* platform/gtk/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137471 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: instrument static parts of RenderBlock and RenderBox
https://bugs.webkit.org/show_bug.cgi?id=104660

Reviewed by Yury Semikhatsky.

Plain vanilla instrumentation.

* dom/WebCoreMemoryInstrumentation.cpp:
(WebCore):
(WebCore::WebCoreMemoryInstrumentation::reportMemoryUsage):
* dom/WebCoreMemoryInstrumentation.h:
(WebCoreMemoryTypes):
(WebCoreMemoryInstrumentation):
(WebCore):
* inspector/InspectorMemoryAgent.cpp:
(WebCore::InspectorMemoryAgent::getProcessMemoryDistribution):
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::reportStaticMembersMemoryUsage):
(WebCore):
* rendering/RenderBlock.h:
(RenderBlock):
* rendering/RenderBox.cpp:
(WebCore::RenderBox::reportStaticMembersMemoryUsage):
(WebCore):
* rendering/RenderBox.h:
(RenderBox):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use render box background over border draw strategy in cases with background-image
https://bugs.webkit.org/show_bug.cgi?id=103409

Reviewed by Simon Fraser.

Source/WebCore:

The BackgroundOverBorderBleedAvoidance mode was not being used in
cases where the background is an opaque image. It was also not
being used in cases with multiple layers. The multiple layer
case is now safe with respect to color bleeding if the top layer
is opaque, thank to the recent addition of layer occlusion culling
in r135629.

No new tests. Testing already covered by the following tests:
fast/backgrounds/background-opaque-images-over-color.html
fast/backgrounds/gradient-background-leakage-2.html

* rendering/RenderBox.cpp:
(WebCore::RenderBox::determineBackgroundBleedAvoidance):
(WebCore::RenderBox::backgroundHasOpaqueTopLayer):
* rendering/RenderBox.h:
(RenderBox):

LayoutTests:

Added image failure expectation for
fast/backgrounds/gradient-background-leakage-2.html which needs
new baselines.

* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137473 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add some entries in the watchlist, and register me for them.

* Scripts/webkitpy/common/config/watchlist:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137474 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Possibility to turn off accessibility feature for WebKit-EFL.
https://bugs.webkit.org/show_bug.cgi?id=103036

Patch by Krzysztof Czech <k.czech@samsung.com> on 2012-12-12
Reviewed by Laszlo Gombos.

Guard dependencies for accessibility (ATK), so that they can be turned off.

.:

* Source/cmake/OptionsEfl.cmake:
* Source/cmake/WebKitFeatures.cmake:

Source/WebCore:

No new tests as there is no new functionality.

* PlatformEfl.cmake:
* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::AccessibilityObject):
* accessibility/AccessibilityObject.h:
(AccessibilityObject):

Tools:

* WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:
(AccessibilityUIElement):
* WebKitTestRunner/PlatformEfl.cmake:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137475 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rebaseline after change to Chromium compositor

Unreviewed gardening.

* platform/chromium-linux/compositing/reflections/reflection-in-composited-expected.png:
* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137476 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Copying text with ruby inserts new lines around rt elements
https://bugs.webkit.org/show_bug.cgi?id=104765

Reviewed by Dan Bernstein.

Source/WebCore: 

Don't emit new lines before and after rt.

Test: editing/pasteboard/copy-paste-ruby-text.html

* editing/TextIterator.cpp:
(WebCore::shouldEmitNewlinesBeforeAndAfterNode):

LayoutTests: 

Added a regression test and rebaseline a test as expected.

* editing/pasteboard/copy-paste-ruby-text-expected.txt: Added.
* editing/pasteboard/copy-paste-ruby-text-with-block-expected.txt: Added.
* editing/pasteboard/copy-paste-ruby-text-with-block.html: Added.
* editing/pasteboard/copy-paste-ruby-text.html: Added.
* editing/selection/paragraph-with-ruby-expected.txt:  new lines around "annotation" has been removed
as expected.
* fast/block/line-layout/selection-highlight-crash-expected.txt:
* fast/ruby/after-doesnt-crash-expected.txt:
* fast/ruby/before-doesnt-crash-expected.txt:
* fast/ruby/parse-rp-expected.txt:
* fast/ruby/ruby-line-height-expected.txt:
* fast/ruby/ruby-text-indent-expected.txt:
* fast/ruby/rubyDOM-insert-rt-block-1-expected.txt:
* fast/ruby/rubyDOM-insert-rt-block-2-expected.txt:
* fast/ruby/rubyDOM-insert-rt-block-3-expected.txt:
* fast/ruby/rubyDOM-remove-rt-block-1-expected.txt:
* fast/ruby/rubyDOM-remove-rt-block-2-expected.txt:
* fast/ruby/rubyDOM-remove-rt-block-3-expected.txt:
* fast/ruby/text-emphasis-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137477 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Grid Layout] Implement CSS parsing and handling for min-content and max-content
https://bugs.webkit.org/show_bug.cgi?id=104747

Reviewed by Alexis Menard.

Source/WebCore:

This change adds -webkit-min-content and -webkit-max-content to our <track-breadth> parsing.
The rendering is not plugged in and will probably depend on bug 103311.

Tests: fast/css-grid-layout/grid-columns-rows-get-set-multiple.html:
       fast/css-grid-layout/grid-columns-rows-get-set.html:

* css/CSSParser.cpp:
(WebCore::CSSParser::parseGridBreadth):
* css/StyleResolver.cpp:
(WebCore::createGridTrackBreadth):
Straight-forward extension of the new code. We were already serializing back properly
so no need to touch CSSComputedStyleDeclaration.

LayoutTests:

Extended the 2 tests to cover -webkit-min-content and -webkit-max-content.

* fast/css-grid-layout/grid-columns-rows-get-set-expected.txt:
* fast/css-grid-layout/grid-columns-rows-get-set-multiple-expected.txt:
* fast/css-grid-layout/grid-columns-rows-get-set-multiple.html:
* fast/css-grid-layout/grid-columns-rows-get-set.html:
* fast/css-grid-layout/resources/grid-columns-rows-get-set-multiple.js:
* fast/css-grid-layout/resources/grid-columns-rows-get-set.js:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137478 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Regions] Two regions reftests are failing the image match
https://bugs.webkit.org/show_bug.cgi?id=74219

Reviewed by Julien Chaffraix.

Modify the 2 tests that were failing on other platforms (chromium, qt, gtk, efl). The tests were failing because different platforms were having different default font-family, font-size
values. I have explicitly set the font-size, font-family and the line-height for the text that will be paginated in regions. Also changed the text color to yellow,
so that we are able to see how the text lines are displayed in each region.

* fast/regions/positioned-objects-block-static-spanning-regions-expected.html:
* fast/regions/positioned-objects-block-static-spanning-regions-rtl-expected.html:
* fast/regions/positioned-objects-block-static-spanning-regions-rtl.html:
* fast/regions/positioned-objects-block-static-spanning-regions.html:
* platform/chromium/TestExpectations:
* platform/efl-wk2/TestExpectations:
* platform/efl/TestExpectations:
* platform/gtk/TestExpectations:
* platform/qt/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137479 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove MediaSource 'ended' to 'open' transition when seeking.
https://bugs.webkit.org/show_bug.cgi?id=104583

Reviewed by Eric Carlson.

Source/WebCore:

Remove the 'ended' to 'open' transition on a seek.

No new tests. The following tests were updated to reflect the new behavior.
  http/tests/media/media-source/video-media-source-seek.html
  http/tests/media/media-source/video-media-source-state-changes.html

* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::seek):

LayoutTests:

Updated seeking tests to no longer expect the the 'ended' to 'open'
transition on a seek.

* http/tests/media/media-source/video-media-source-seek-expected.txt:
* http/tests/media/media-source/video-media-source-seek.html:
* http/tests/media/media-source/video-media-source-state-changes-expected.txt:
* http/tests/media/media-source/video-media-source-state-changes.html:
* platform/chromium/TestExpectations:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137480 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Animation fails on large layers
https://bugs.webkit.org/show_bug.cgi?id=104538

Reviewed by Noam Rosenthal.

The backing tiles had no upper limit defined for the non-GL backend, which could cause them
to allocate pixmaps widier or higher than what the underlying graphics systems can handle.

On top of that GraphicsLayerTextureMapper::prepareBackingStore() would allocate an intermediate
pixmap the size of the dirty rect, which would at least on the first paint be the size of the
entire layer, again causing allocation of pixmaps with dimensions outside of platform bounds.

This patch introduces a limit to the size of image buffer tiles, and adds an alternative path
for painting where the GraphicsLayer paints directly to the tile instead of over an intermediate
pixmap. This alternative path can also be useful later to minimize the amount of pixel copying
happening in full repaints.

* platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:
(WebCore::GraphicsLayerTextureMapper::prepareBackingStore):
* platform/graphics/texmap/GraphicsLayerTextureMapper.h:
(GraphicsLayerTextureMapper):
* platform/graphics/texmap/TextureMapper.cpp:
(WebCore::BitmapTexture::updateContents):
* platform/graphics/texmap/TextureMapper.h:
(BitmapTexture):
(TextureMapper):
* platform/graphics/texmap/TextureMapperBackingStore.cpp:
(WebCore::TextureMapperTile::updateContents):
(WebCore::TextureMapperTiledBackingStore::updateContents):
* platform/graphics/texmap/TextureMapperBackingStore.h:
(TextureMapperTile):
(TextureMapperTiledBackingStore):
* platform/graphics/texmap/TextureMapperImageBuffer.cpp:
(WebCore::BitmapTextureImageBuffer::updateContents):
(WebCore::TextureMapperImageBuffer::maxTextureSize):
* platform/graphics/texmap/TextureMapperImageBuffer.h:
(BitmapTextureImageBuffer):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137481 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Add destructor to WebPrerender
https://bugs.webkit.org/show_bug.cgi?id=104820

Reviewed by James Robinson.

When making WebPrerender default constructible and assignable, the destructor should have been moved out of WEBKIT_IMPLEMENTATION.

Source/Platform:

* chromium/public/WebPrerender.h:
(WebKit::WebPrerender::~WebPrerender):
(WebPrerender):

Source/WebCore:

Existing WebKit unit tests should test this, as do chromium browser tests.

* platform/chromium/support/WebPrerender.cpp:
(WebKit::WebPrerender::toPrerender):
(WebKit::WebPrerender::reset):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137482 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK][AC] The non-composited content is not painted
https://bugs.webkit.org/show_bug.cgi?id=104819

Reviewed by Gustavo Noronha Silva.

When Accelerated Compositing is enabled, only GraphicsLayers are painted.
This patch allows to paint the non-composited content on the viewport with
GraphicsLayers. Most of the codes are the same as AcceleratedCompositingContextGL.cpp

* WebCoreSupport/AcceleratedCompositingContext.h: Add m_nonCompositedContentLayer.
* WebCoreSupport/AcceleratedCompositingContextClutter.cpp:
(WebKit::AcceleratedCompositingContext::AcceleratedCompositingContext):
(WebKit::AcceleratedCompositingContext::initialize):
(WebKit):
(WebKit::AcceleratedCompositingContext::~AcceleratedCompositingContext):
(WebKit::AcceleratedCompositingContext::renderLayersToWindow):
(WebKit::AcceleratedCompositingContext::setRootCompositingLayer):
(WebKit::AcceleratedCompositingContext::setNonCompositedContentsNeedDisplay):
(WebKit::AcceleratedCompositingContext::resizeRootLayer):
(WebKit::AcceleratedCompositingContext::scrollNonCompositedContents): Make the non-composited
content scroll.
(WebKit::AcceleratedCompositingContext::layerFlushTimerFiredCallback):
(WebKit::AcceleratedCompositingContext::flushPendingLayerChanges):
(WebKit::AcceleratedCompositingContext::flushAndRenderLayers):
(WebKit::AcceleratedCompositingContext::notifyAnimationStarted):
(WebKit::AcceleratedCompositingContext::paintContents): Paint the non-composited content.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137483 268f45cc-cd09-0410-ab3c-d52691b4dbfc
AX: aria-busy should be exposed everywhere, not just on live regions
https://bugs.webkit.org/show_bug.cgi?id=104814

Reviewed by Anders Carlsson.

Source/WebCore:

The aria-busy attribute should be exposed on all elements.
This isn't entirely clear in the ARIA spec, but that will be fixed with
ARIA1.1 (ISSUE-538).

Existing tests that dump attributes cover this new behavior.

* accessibility/mac/WebAccessibilityObjectWrapper.mm:
(-[WebAccessibilityObjectWrapper additionalAccessibilityAttributeNames]):

LayoutTests:

Update tests that dump all attributes to include aria busy attribute.

* accessibility/transformed-element-expected.txt:
* platform/mac/accessibility/aria-liveregions-attributes-expected.txt:
* platform/mac/accessibility/bounds-for-range-expected.txt:
* platform/mac/accessibility/document-attributes-expected.txt:
* platform/mac/accessibility/document-links-expected.txt:
* platform/mac/accessibility/image-link-expected.txt:
* platform/mac/accessibility/image-map2-expected.txt:
* platform/mac/accessibility/internal-link-anchors-expected.txt:
* platform/mac/accessibility/internal-link-anchors2-expected.txt:
* platform/mac/accessibility/lists-expected.txt:
* platform/mac/accessibility/plugin-expected.txt:
* platform/mac/accessibility/radio-button-group-members-expected.txt:
* platform/mac/accessibility/table-attributes-expected.txt:
* platform/mac/accessibility/table-cell-spans-expected.txt:
* platform/mac/accessibility/table-cells-expected.txt:
* platform/mac/accessibility/table-detection-expected.txt:
* platform/mac/accessibility/table-one-cell-expected.txt:
* platform/mac/accessibility/table-sections-expected.txt:
* platform/mac/accessibility/table-with-aria-role-expected.txt:
* platform/mac/accessibility/table-with-rules-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137484 268f45cc-cd09-0410-ab3c-d52691b4dbfc
garden-o-matic should prefer efl/ over efl-wk1/ and efl-wk2/ when rebaselining
https://bugs.webkit.org/show_bug.cgi?id=102389

Reviewed by Tony Chang.

The code wasn't aware of both the efl-wk1 and efl-wk2 variants,
because all_port_names() by itself doesn't tell you about the
variants. Work around this for now, and filed bug 104761 to
address the underlying problem.

* Scripts/webkitpy/common/checkout/baselineoptimizer.py:
* Scripts/webkitpy/common/checkout/baselineoptimizer_unittest.py:
(BaselineOptimizerTest.test_efl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137485 268f45cc-cd09-0410-ab3c-d52691b4dbfc