Reproducible "Unhanded web process message 'WebUserContentController:AddUserScripts...
authortimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 22 Jan 2016 22:25:56 +0000 (22:25 +0000)
committertimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 22 Jan 2016 22:25:56 +0000 (22:25 +0000)
commitc773b46876bb6a0739287186a67ed3a8a903eed5
tree5741ba49999e747612b5d450678bce740611db56
parentcad3d650c0b527c1d1b368020f38d71529497d6d
Reproducible "Unhanded web process message 'WebUserContentController:AddUserScripts'" and friends
https://bugs.webkit.org/show_bug.cgi?id=153193
<rdar://problem/24222034>

Reviewed by Darin Adler.

The WebPageProxy constructor assumes that if its WebProcess is already running,
it can add itself to the existing WebUserContentController(Proxy) and all will be well.

However, if the API client constructs a different WKUserContentController for two views,
and forces them both into the same process, WebPageProxy's constructor sends a message
with a WebUserContentController ID that doesn't exist yet on the WebProcess side
(because createWebPage, which usually brings it up, hasn't happened yet), and we
drop the message on the floor (and get the aforementioned logging).

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::WebPageProxy):
(WebKit::WebPageProxy::initializeWebPageAfterProcessLaunch):
Instead of connecting our WebUserContentControllerProxy and WebVisitedLinkStoreProxy
to our WebProcessProxy in the constructor, when doing so might send messages
to the WebProcess that arrive before their corresponding WebProcess objects have
been created, do this in initializeWebPageAfterProcessLaunch, which always runs
during-or-after inititalizeWebPage (and always after the CreateWebPage message goes out).

(WebKit::WebPageProxy::initializeWebPage):
Mark us as needing initializeWebPageAfterProcessLaunch run, and run it right now
if the WebProcess is already up.
(WebKit::WebPageProxy::processDidFinishLaunching):
If the WebProcess wasn't up at the end of initializeWebPage, we'll eventually end up here
after it is launched, and will initializeWebPageAfterProcessLaunch.

(WebKit::WebPageProxy::resetStateAfterProcessExited):
If the WebProcess dies, we don't want to initializeWebPageAfterProcessLaunch
until after initializeWebPage runs again, so make sure the flag isn't set.

* UIProcess/WebPageProxy.h:

* TestWebKitAPI/Tests/WebKit2Cocoa/UserContentController.mm:
(webViewForScriptMessageHandlerMultipleHandlerRemovalTest):
(TEST):
Add a test that exhibits the problems we're fixing here.
Before, it would both log and assert in debug, and crash in release.
Now it runs happily to completion.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@195479 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit2/ChangeLog
Source/WebKit2/UIProcess/WebPageProxy.cpp
Source/WebKit2/UIProcess/WebPageProxy.h
Tools/ChangeLog
Tools/TestWebKitAPI/Tests/WebKit2Cocoa/UserContentController.mm