<rdar://problem/12834449> Crashes in WebSocketChannel::processFrame when processing a ping
        https://bugs.webkit.org/show_bug.cgi?id=114178

        Reviewed by Brady Eidson.

        No test, I could never reproduce even manually.

        Calling enqueueRawFrame() could change incoming buffer, so a subsequent skipBuffer()
        would operate on wrong assumptions. This happened because enqueueRawFrame() actually
        tried to process the queue, and send failure sometimed clears m_buffer.

        Fixing this by decoupling enqueuing from sending, and making sure that skipBuffer()
        in ping frame processing case is performed at a safe time.

        * Modules/websockets/WebSocketChannel.cpp:
        (WebCore::WebSocketChannel::send):
        (WebCore::WebSocketChannel::startClosingHandshake):
        (WebCore::WebSocketChannel::processFrame):
        (WebCore::WebSocketChannel::enqueueTextFrame):
        (WebCore::WebSocketChannel::enqueueRawFrame):
        (WebCore::WebSocketChannel::enqueueBlobFrame):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147938 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r147850.
http://trac.webkit.org/changeset/147850
https://bugs.webkit.org/show_bug.cgi?id=113706

Changeset crossed paths with 147505, which is the same fix.

Source/WebCore:

* rendering/RenderBlockLineLayout.cpp:
(WebCore::inlineLogicalWidth):

LayoutTests:

* fast/inline/inline-with-empty-inline-children-expected.txt:
* fast/inline/inline-with-empty-inline-children.html:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147939 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove some #includes in headers in rendering code
https://bugs.webkit.org/show_bug.cgi?id=114079

Reviewed by Sam Weinig.

Clean up #includes in RenderObject, RenderLayer etc.
Moved makeMatrixRenderable() into RenderLayer.app, allowing
the removal of a TransformationMatrix.h include.

Make some RenderLayer functions that deal with filters not inline,
to avoid including RenderLayerFilterInfo.h.

* platform/graphics/GraphicsLayer.h:
* platform/graphics/ImageOrientation.cpp:
* platform/graphics/cairo/GraphicsContextCairo.cpp:
* platform/graphics/qt/GraphicsContextQt.cpp:
* platform/graphics/transforms/AffineTransform.cpp:
* platform/graphics/transforms/AffineTransform.h:
* rendering/RenderBoxModelObject.h:
* rendering/RenderLayer.cpp:
(WebCore::makeMatrixRenderable):
(WebCore::RenderLayer::filterRenderer):
(WebCore::RenderLayer::filterInfo):
(WebCore::RenderLayer::ensureFilterInfo):
(WebCore::RenderLayer::removeFilterInfoIfNeeded):
* rendering/RenderLayer.h:
* rendering/RenderLayerBacking.h:
* rendering/RenderLineBoxList.h:
* rendering/RenderObject.h:

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

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147941 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Simplify ContainerNode::removeChildren
https://bugs.webkit.org/show_bug.cgi?id=113517

Reviewed by Darin Adler.

The patch is based on the work made by Elliott Sprehn. He kindly agreed
for me to finalize the last bits and pieces of the fix.

Source/WebCore:

Simplify ContainerNode::removeChildren by merging the loops and removing
willRemoveChildren. This removes two traversals of the children, avoids
refing and derefing all the children once, avoids allocating a second
NodeVector of children, and means we detach() in the same order as
normal removal.

This does mean you can get into an infinite loop with DOMNodeRemoved
listeners by continously adding nodes but this is true in all other browsers
and the current behavior is bad because it means you don't get notified
of nodes added during removal (which other browsers do notify of). This
patch removes the containerNode.html test that originally tested for this
infinite loop and adds a new one that tests that all nodes get notified.

This makes PerformanceTests/Parser/innerHTML-setter.html 2-6% faster.

There's also a new test verifying ranges remain consistent if modified
inside an mutation event handler. Without the patch it's possible to create
a range with boundaries outside of the DOM tree.

Tests: fast/dom/Range/range-remove-children-event.html
       fast/events/mutation-during-innerHTML.html

* dom/ContainerNode.cpp:
(WebCore::ContainerNode::removeChildren):
* dom/Document.cpp:
* dom/Document.h: nodeChildrenWillBeRemoved is not needed any more.
* dom/Range.cpp:
* dom/Range.h: nodeChildrenWillBeRemoved is not needed any more.

LayoutTests:

Remove containerNode.html test since it was checking for an infinite
loop when adding DOM nodes inside a DOMNodeRemoved mutation event
handler, but we actually do want to allow an infinite loop here for
correctness and compatability with other browsers.

Also added mutation-during-innerHTML which checks that all nodes
are notified of being removed even if they were added during the
DOMNodeRemoved notification.

There's a new test range-remove-children-event that verifies the
ranges modified inside a mutation event handler remain consistent.

* fast/dom/MutationObserver/added-out-of-order-expected.txt:
* fast/dom/MutationObserver/added-out-of-order.html:
* fast/dom/Range/range-remove-children-event-expected.txt: Added.
* fast/dom/Range/range-remove-children-event.html: Added.
* fast/dom/containerNode-expected.txt: Removed.
* fast/dom/containerNode.html: Removed.
* fast/events/mutation-during-innerHTML-expected.txt: Added.
* fast/events/mutation-during-innerHTML.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147942 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed gardening. Remove expected results added by r147824.

* platform/mac-future/accessibility/press-action-is-first-expected.txt: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147943 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove my watchlist entries.
https://bugs.webkit.org/show_bug.cgi?id=114180

Reviewed by Adam Barth.

* Scripts/webkitpy/common/config/committers.py:
* Scripts/webkitpy/common/config/watchlist:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147944 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] More null checks for m_mainFrame
https://bugs.webkit.org/show_bug.cgi?id=114172

Patch by Jakob Petsovits <jpetsovits@blackberry.com> on 2013-04-08
Reviewed by Rob Buis.

After r147744, some unit tests were crashing on WebPage
shutdown, because BackingStorePrivate::repaint() now uses
pixelContentsRect() (accessing m_webPage->contentsRect())
instead of BackingStoreClient::contentsRect(). In m_webPage,
m_mainFrame had already been set to 0.

Make us more robust against these errors by checking
the existence of m_mainFrame more diligently.

* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::shouldZoomAboutPoint):
(BlackBerry::WebKit::WebPagePrivate::shouldSendResizeEvent):
(BlackBerry::WebKit::WebPagePrivate::contentsSize):
(BlackBerry::WebKit::WebPagePrivate::absoluteVisibleOverflowSize):
(BlackBerry::WebKit::WebPagePrivate::setViewMode):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147945 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Bump gnome-themes-standard to 3.6.0
https://bugs.webkit.org/show_bug.cgi?id=114155

Patch by Manuel Rego Casasnovas <rego@igalia.com> on 2013-04-08
Reviewed by Martin Robinson.

* gtk/jhbuild.modules: As now we depend on GTK+ 3.6.0 bump the
dependency of gnome-themes-standard accordingly.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147946 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make resolve more robust in the face of lookup misses
https://bugs.webkit.org/show_bug.cgi?id=114211

Reviewed by Filip Pizlo.

This simply short circuits the resolve operations in the
event that we don't find a path to a property.  There's no
repro case for this happening unfortunately.

* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147947 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Windows build fix.

* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147948 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash in ScrollingCoordinator::mainThreadScrollingReasons() when going back
https://bugs.webkit.org/show_bug.cgi?id=114214
-and corresponding-
<rdar://problem/13208616>

Reviewed by Anders Carlsson.

When a page is restoring from the page cache, the mainFrame can have a null 
Document. So we should null-check the Document here. 

* page/scrolling/ScrollingCoordinator.cpp:
(WebCore::ScrollingCoordinator::mainThreadScrollingReasons):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147949 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Windows build fix fix.

* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147950 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Configure should verify ICU is installed on mingw
https://bugs.webkit.org/show_bug.cgi?id=113645

Patch by Martin Robinson <mrobinson@igalia.com> on 2013-04-08
Reviewed by Gustavo Noronha Silva.

* Source/autotools/FindDependencies.m4: When falling back to hard-coded compiler flags
for ICU and mingw, check that headers do exist on the system and error out otherwise.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147951 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add an async version of ResourceHandle::didReceiveResponse
https://bugs.webkit.org/show_bug.cgi?id=114215

Reviewed by Sam Weinig.

Source/WebCore:

In order to support converting NSURLConnections to NSURLDownloads when using the network process
we need an async version of didReceiveResponse.

* WebCore.exp.in:
* platform/network/ResourceHandleClient.cpp:
(WebCore::ResourceHandleClient::didReceiveResponseAsync):
Just call continueDidReceiveResponse().

* platform/network/mac/ResourceHandleMac.mm:
(WebCore::ResourceHandle::continueWillSendRequest):
Split up a single condition in two, making it easier to see which assertion fails.

(WebCore::ResourceHandle::continueDidReceiveResponse):
Call -[WebCoreResourceHandleAsOperationQueueDelegate continueDidReceiveResponse].

(WebCore::ResourceHandle::continueShouldUseCredentialStorage):
(WebCore::ResourceHandle::continueCanAuthenticateAgainstProtectionSpace):
(WebCore::ResourceHandle::continueWillCacheResponse):
Split up a single condition in two, making it easier to see which assertion fails.

* platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.h:
* platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm:
(-[WebCoreResourceHandleAsOperationQueueDelegate continueDidReceiveResponse]):
Signal the semaphore.

(-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveResponse:]):
Call didReceiveResponseAsync on the main thread and wait on the semaphore.

Source/WebKit2:

* NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::didReceiveResponseAsync):
Send the message and then call continueDidReceiveResponse.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147952 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web/Plugin process deadlock initializing async plugins.
<rdar://problem/13525232> and https://bugs.webkit.org/show_bug.cgi?id=114217

Reviewed by Anders Carlsson.

       The "Async initialization complete" messages probably don't have to be synchronous.

* PluginProcess/WebProcessConnection.cpp:
(WebKit::WebProcessConnection::createPluginAsynchronously): Notify of initialization success/failure asynchronously.
* WebProcess/Plugins/PluginProxy.messages.in:

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

* platform/network/ResourceHandle.cpp:
(WebCore::ResourceHandle::continueDidReceiveResponse):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147954 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r138858): Crash in WebCore::FrameLoader::~FrameLoader() when opening page in a background tab
https://bugs.webkit.org/show_bug.cgi?id=109935
<rdar://problem/13225963>

Reviewed by Brady Eidson.

Previously, we were deciding if a Page could go into
the PageCache by blacklisting certain load types. Instead,
whitelist the load types that we know can go into the cache,
so that newly-added load types are not cached unless
that is explicitly desired.

The crash occurs when a page which is actively loading
is put into the page cache while doing a redirect with
FrameLoadTypeRedirectWithLockedBackForwardList (note that
this is a redirect that was not covered in the blacklist),
and then promptly removed from the page cache, resulting
in resources from the redirect target (the now-active page)
being incorrectly destroyed.

No new tests, only known crash repro case is extremely
timing dependent (and only happens in WebKit2, with tiled
drawing, in background tabs).

* history/PageCache.cpp:
(WebCore::PageCache::canCache):

Adjust a test which depended on slow-redirects going
into the page cache (which will no longer happen)
to instead click on a link.

* fast/history/timed-refresh-in-cached-frame.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147955 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Call Netscape Plugin's toString() and valueOf() instead of providing default implementation
https://bugs.webkit.org/show_bug.cgi?id=113139

Patch by Arunprasad Rajkumar <arunprasadr@nds.com> on 2013-04-08
Reviewed by Anders Carlsson.

Source/WebCore:

Tests: plugins/npruntime/tostring.html
       plugins/npruntime/valueof.html

* bridge/c/c_instance.cpp:
(JSC::Bindings::CInstance::~CInstance):
(JSC::Bindings::CInstance::invokeMethod):
(JSC::Bindings::CInstance::invokeDefaultMethod):
(Bindings):
(JSC::Bindings::CInstance::invokeConstruct):
(JSC::Bindings::CInstance::stringValue):
(JSC::Bindings::CInstance::booleanValue):
(JSC::Bindings::CInstance::valueOf):
(JSC::Bindings::CInstance::toJSPrimitive):
* bridge/c/c_instance.h:
(CInstance):

Tools:

* DumpRenderTree/DumpRenderTree.vcxproj/TestNetscapePlugin/TestNetscapePlugin.vcxproj:
* DumpRenderTree/DumpRenderTree.vcxproj/TestNetscapePlugin/TestNetscapePlugin.vcxproj.filters:
* DumpRenderTree/TestNetscapePlugIn/CMakeLists.txt:
* DumpRenderTree/TestNetscapePlugIn/Tests/ToStringAndValueOfObject.cpp: Added.
(ToStringAndValueOfObject):
(ToStringAndValueOfObject::ToStringAndValueOfObject):
(ScriptableObject):
(ToStringAndValueOfObject::ScriptableObject::hasMethod):
(ToStringAndValueOfObject::ScriptableObject::invoke):
(ToStringAndValueOfObject::ScriptableObject::pluginTest):
(ToStringAndValueOfObject::NPP_GetValue):
* DumpRenderTree/TestNetscapePlugIn/win/TestNetscapePlugin.vcproj:
* DumpRenderTree/qt/TestNetscapePlugin/TestNetscapePlugin.pro:
* GNUmakefile.am:

LayoutTests:

* platform/qt-mac/TestExpectations:
* platform/wk2/TestExpectations:
* plugins/npruntime/tostring-expected.txt: Added.
* plugins/npruntime/tostring.html: Added.
* plugins/npruntime/valueof-expected.txt: Added.
* plugins/npruntime/valueof.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147956 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use port 6665 instead of 6667 since the latter doesn't seem to work well.

* Scripts/webkitpy/common/config/irc.py:


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