nrwt: don't wait for safari to exit before exiting after showing the results file
https://bugs.webkit.org/show_bug.cgi?id=81845

Reviewed by Ryosuke Niwa.

Prior to this change, if you ran new-run-webkit-tests and
displayed the HTML results file at the end, we would block
waiting for the user to quit the browser. There doesn't seem to
be a need for that, and the Chromium ports don't do this.

Also, update the mac tests to capture the output and be quiet :).

* Scripts/webkitpy/common/system/executive_mock.py:
  Make popen() testable, implement should_log for it.
* Scripts/webkitpy/layout_tests/port/mac.py:
(MacPort.show_results_html_file):
* Scripts/webkitpy/layout_tests/port/mac_unittest.py:
  Silence some of the tests via outputcapture.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111945 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION: can select text of an input button
https://bugs.webkit.org/show_bug.cgi?id=13624

Patch by Parag Radke <parag@motorola.com> on 2012-03-23
Reviewed by Ryosuke Niwa.

Source/WebCore: 

Text in a button should never have a selection background of its own painted
but if the button is inside an editable area, then the whole button should
have it's selection background painted.

Test: editing/selection/selection-button-text.html

* rendering/RenderButton.h:
Added implementation for the virtual function canBeSelectionLeaf()
which returns true if the button renderer is editable, false other wise.
* rendering/RenderTextFragment.h:
Added implementation for the virtual function canBeSelectionLeaf()
which returns true if the text fragment renderer is editable, false other wise.

LayoutTests: 

Added a pixel test case to test the selection background for button label text.

* editing/selection/selection-button-text.html: Added.
* platform/gtk/editing/selection/selection-button-text-expected.png: Added.
* platform/gtk/editing/selection/selection-button-text-expected.txt: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move WebSocket APIs from WorkerContext.idl to WorkerContextWebSocket.idl
https://bugs.webkit.org/show_bug.cgi?id=79663

Reviewed by Adam Barth.

For WebKit modularization, this patch moves WebSocket APIs from WorkerContext.idl
to WorkerContextWebSocket.idl.

Tests: http/tests/websocket/tests/hybi/workers/* (No change in test results)

* CMakeLists.txt:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* Modules/websockets/WorkerContextWebSocket.idl: Added.
* WebCore.gypi:
* WebCore.xcodeproj/project.xcodeproj:
* workers/WorkerContext.idl:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111949 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[MutationObservers] attributeFilter should be case sensitive at all times
https://bugs.webkit.org/show_bug.cgi?id=81822

Reviewed by Ryosuke Niwa.

Source/WebCore:

This removes the behavior in MutationObserverRegistration which treats
attributeFilter as case insensitive for HTML elements in HTML documents.

Relevant tests have been updated.

* dom/MutationObserverRegistration.cpp:
(WebCore::MutationObserverRegistration::resetObservation):
(WebCore::MutationObserverRegistration::shouldReceiveMutationFrom):
* dom/MutationObserverRegistration.h:
(MutationObserverRegistration):

LayoutTests:

* fast/mutation/observe-attributes-expected.txt:
* fast/mutation/observe-attributes.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111950 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Add WebPageCompositor class to BlackBerry WebKit API
https://bugs.webkit.org/show_bug.cgi?id=81121
RIM PR: 136687

Patch by Arvid Nilsson <anilsson@rim.com> on 2012-03-23
Reviewed by Rob Buis.

The idea is for the API client to use a WebPageCompositor object to
render the WebPage when there's no screen window available.

The WebPageCompositorPrivate becomes reference counted in order to be
kept alive either because it's used for accelerated compositing layers
or used for the WebPageCompositor API. It can still work standalone.

Clean up some code - no need to keep track of a separate boolean
WebPagePrivate::m_isAcceleratedCompositingActive when the state of
m_compositor can tell you.

Also remove duplicated code from WebPagePrivate - go directly to the
compositor object instead, if you need to draw the AC layers.

Reviewed internally by Robin Cao and the hasBlitJobs/blitOnIdle change
by Filip Spacek.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStore::hasBlitJobs):
(BlackBerry::WebKit::BackingStore::blitOnIdle):
(BlackBerry::WebKit::BackingStorePrivate::blitContents):
(BlackBerry::WebKit::BackingStorePrivate::drawSubLayers):
(BlackBerry::WebKit::BackingStorePrivate::drawAndBlendLayersForDirectRendering):
(BlackBerry::WebKit::BackingStorePrivate::surfaceSize):
(BlackBerry::WebKit::BackingStorePrivate::buffer):
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::WebPagePrivate):
(BlackBerry::WebKit::WebPagePrivate::drawLayersOnCommit):
(BlackBerry::WebKit::WebPagePrivate::setCompositor):
(BlackBerry::WebKit::WebPagePrivate::setRootLayerCompositingThread):
(BlackBerry::WebKit::WebPagePrivate::createCompositor):
(BlackBerry::WebKit::WebPagePrivate::destroyCompositor):
* Api/WebPage.h:
* Api/WebPageCompositor.cpp:
(BlackBerry::WebKit::WebPageCompositorPrivate::WebPageCompositorPrivate):
(BlackBerry::WebKit::WebPageCompositorPrivate::setContext):
(BlackBerry::WebKit::WebPageCompositorPrivate::hardwareCompositing):
(BlackBerry::WebKit::WebPageCompositorPrivate::setRootLayer):
(BlackBerry::WebKit::WebPageCompositorPrivate::render):
(BlackBerry::WebKit::WebPageCompositorPrivate::drawLayers):
(BlackBerry::WebKit::WebPageCompositorPrivate::animationTimerFired):
(BlackBerry::WebKit::WebPageCompositorPrivate::compositorDestroyed):
(BlackBerry::WebKit::WebPageCompositor::WebPageCompositor):
(BlackBerry::WebKit::WebPageCompositor::~WebPageCompositor):
(BlackBerry::WebKit::WebPageCompositor::client):
(BlackBerry::WebKit::WebPageCompositor::prepareFrame):
(BlackBerry::WebKit::WebPageCompositor::render):
(BlackBerry::WebKit::WebPageCompositor::cleanup):
(BlackBerry::WebKit::WebPageCompositor::contextLost):
* Api/WebPageCompositor.h: Added.
* Api/WebPageCompositorClient.h: Added.
* Api/WebPageCompositor_p.h:
(BlackBerry::WebKit::WebPageCompositorPrivate::create):
(BlackBerry::WebKit::WebPageCompositorPrivate::context):
(BlackBerry::WebKit::WebPageCompositorPrivate::animationFrameTimestamp):
(BlackBerry::WebKit::WebPageCompositorPrivate::page):
(BlackBerry::WebKit::WebPageCompositorPrivate::client):
* Api/WebPage_p.h:
(BlackBerry::WebKit::WebPagePrivate::client):
(BlackBerry::WebKit::WebPagePrivate::isAcceleratedCompositingActive):
(BlackBerry::WebKit::WebPagePrivate::compositor):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111959 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix Chromium 10.6/10.5 tests that broke with r111917. There's a bug
with garden-o-matic when rebaselining all the Chromium Mac ports.
Other ports seem fine.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111961 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Fix race bug that clobbers CCLayerImpl updateRect
https://bugs.webkit.org/show_bug.cgi?id=82109

Reviewed by Dirk Pranke.

Source/WebCore:

If the main thread commits twice before the impl thread actually
draws, then the updateRect of the first frame gets lost forever,
and not propagated to the damage tracker.

The solution is to accumulate the updateRect. The CCLayerImpl
updateRect is already being correctly cleared at the appropriate
time after drawing.

Unit test added to LayerChromiumTest.cpp.

* platform/graphics/chromium/LayerChromium.cpp:
(WebCore::LayerChromium::pushPropertiesTo):

Source/WebKit/chromium:

* tests/LayerChromiumTest.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111963 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] RootLayer was not being checked for null causing segfaults very rarely.
https://bugs.webkit.org/show_bug.cgi?id=82111

Patch by Michal Mocny <mmocny@google.com> on 2012-03-23
Reviewed by Adrienne Walker.

* platform/graphics/chromium/LayerRendererChromium.cpp:
(WebCore::LayerRendererChromium::beginDrawingFrame):
* platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:
(WebCore::CCLayerTreeHostImpl::drawLayers):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111968 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Move Notifications APIs from WorkerContext.idl to WorkerContextNotifications.idl
https://bugs.webkit.org/show_bug.cgi?id=79635

Reviewed by Kentaro Hara.

This patch moves the NotificationCenter from WorkerContext to
WorkerContextNotificiations, reducing clutter in WorkerContext.  After
this patch, Notifications are almost entirely contained in the
notifications directory.

* CMakeLists.txt:
* DerivedSources.make:
* DerivedSources.pri:
* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* workers/WorkerContext.cpp:
(WebCore::WorkerContext::~WorkerContext):
* workers/WorkerContext.h:
(WebCore):
(WorkerContext):
* workers/WorkerContext.idl:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111969 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] CCLayerTreeHostImpl::scrollBegin() should return ScrollFailed for CCInputHandlerClient::Gesture type when wheel handlers found.
https://bugs.webkit.org/show_bug.cgi?id=82106

Reviewed by Adrienne Walker.

Source/WebCore:

Existing unit tests updated.

With gesture scroll events now being handled as mouse wheel events, we should not start a gesture scroll when
wheel handlers are present.

* platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:
(WebCore::CCLayerTreeHostImpl::scrollBegin):

Source/WebKit/chromium:

* tests/CCLayerTreeHostImplTest.cpp:
(WebKit::TEST_F):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111971 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix more Chromium 10.6/10.5 tests that broke with r111917. There's a bug
with garden-o-matic when rebaselining all the Chromium Mac ports.
Other ports seem fine.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111972 268f45cc-cd09-0410-ab3c-d52691b4dbfc
tryReallocate could break the zero-ed memory invariant of CopiedBlocks
https://bugs.webkit.org/show_bug.cgi?id=82087

Reviewed by Filip Pizlo.

Removing this optimization turned out to be ~1% regression on kraken, so I simply
undid the modification to the current block if we fail.

* heap/CopiedSpace.cpp:
(JSC::CopiedSpace::tryReallocate): Undid the reset in the CopiedAllocator if we fail
to reallocate from the current block.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111973 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DFG Fixup should be able to short-circuit trivial ValueToInt32's
https://bugs.webkit.org/show_bug.cgi?id=82030

Reviewed by Michael Saboff.
        
Takes the fixup() method of the prediction propagation phase and makes it
into its own phase. Adds the ability to short-circuit trivial ValueToInt32
nodes, and mark pure ValueToInt32's as such.

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCommon.h:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGFixupPhase.cpp: Added.
(DFG):
(FixupPhase):
(JSC::DFG::FixupPhase::FixupPhase):
(JSC::DFG::FixupPhase::run):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixIntEdge):
(JSC::DFG::performFixup):
* dfg/DFGFixupPhase.h: Added.
(DFG):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::run):
(PredictionPropagationPhase):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111974 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Updated the Mac expected results for this test after CSS shaders were disabled in r111893.
WebKitCSSFilterValue.CSS_FILTER_CUSTOM is no longer defined.

* platform/mac/fast/dom/Window/window-properties-expected.txt:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=81963 WebProcess can get stuck in GC during many low memory signals.
<rdar://problem/11094830> WebProcess appears to get stuck in its GC handler (81963).
Remove the call to garbage collect  in low memory signal handler.  Did some testing with hitting the low memory handler
during Membuster and we would get back at most 100k - 200k.  That isn't enough to help the system, and in
that state the GC collection can take a substantial amount of time.

Reviewed by Geoff Garen.

Performance Change, no change in behavior.

* platform/mac/MemoryPressureHandlerMac.mm:
(WebCore::MemoryPressureHandler::releaseMemory):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111977 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] When prepainting fails, tiles dirty rects may be cleared
https://bugs.webkit.org/show_bug.cgi?id=82107

Patch by Dana Jansens <danakj@chromium.org> on 2012-03-23
Reviewed by Adrienne Walker.

Source/WebCore:

When prepainting, if a tile is unable to be reserved due to memory
limits, we bail out of prepareToUpdateTiles. But we would have
cleared the dirty rect of any previous tiles. This leaves them
in a bad state where their textures are reserved, but their textureIds
are set to 0, and they are not marked dirty. This means that they will
not be updated and displayed if they become visible, since it is
assumed that valid textures with zero textureId must have a dirty
region.

We fix this by not clearing the dirty rects until we know we are
going to update the layer.

Unit test: TiledLayerChromiumTest.pushTilesAfterIdlePaintFailed

* platform/graphics/chromium/TiledLayerChromium.cpp:
(WebCore::TiledLayerChromium::prepareToUpdateTiles):
* platform/graphics/chromium/cc/CCTiledLayerImpl.cpp:
(WebCore::CCTiledLayerImpl::hasTextureIdForTileAt):
(WebCore):
* platform/graphics/chromium/cc/CCTiledLayerImpl.h:
(CCTiledLayerImpl):

Source/WebKit/chromium:

* tests/TiledLayerChromiumTest.cpp:
(WTF::FakeTextureAllocator::createTexture):
(WTF::FakeLayerTextureUpdater::Texture::updateRect):
(FakeCCTiledLayerImpl):
(WTF::FakeCCTiledLayerImpl::hasTextureIdForTileAt):
(WTF::TEST):
(WTF):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111978 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Not reviewed: chromium expectations updated.

* platform/chromium/test_expectations.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111979 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Not reviewed: adding chromium baselines.

* platform/chromium-linux/editing/selection/selection-button-text-expected.png: Added.
* platform/chromium-linux/editing/selection/selection-button-text-expected.txt: Added.
* platform/chromium-mac-leopard/editing/selection/selection-button-text-expected.png: Added.
* platform/chromium-mac-snowleopard/editing/selection/selection-button-text-expected.png: Added.
* platform/chromium-mac/editing/selection/selection-button-text-expected.png: Added.
* platform/chromium-mac/editing/selection/selection-button-text-expected.txt: Added.
* platform/chromium-win-vista/editing/selection/selection-button-text-expected.png: Added.
* platform/chromium-win-vista/editing/selection/selection-button-text-expected.txt: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111980 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Not reviewed: chromium expectations updated.

* platform/chromium/test_expectations.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@111981 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Incorrect replica originTransform used in CCDamageTracker
https://bugs.webkit.org/show_bug.cgi?id=82118

Reviewed by Adrienne Walker.

Source/WebCore:

Unit test added to CCDamageTrackerTest.cpp

* platform/graphics/chromium/cc/CCDamageTracker.cpp:
(WebCore::CCDamageTracker::extendDamageForRenderSurface):

Source/WebKit/chromium:

* tests/CCDamageTrackerTest.cpp:
(WebKitTests::TEST_F):
(WebKitTests):


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