UIProcess should process incoming sync IPC from WebProcess when waiting for a sync...
authorcdumez@apple.com <cdumez@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 26 Sep 2018 18:38:26 +0000 (18:38 +0000)
committercdumez@apple.com <cdumez@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 26 Sep 2018 18:38:26 +0000 (18:38 +0000)
commit1001ca4b09da175ebab85b49155b593ae1868f39
tree6fe5f5a1324963c5f596e1528ab43884dac8e97d
parentec32e9f822e5d536c7d5c72d730b5dcd268956d1
UIProcess should process incoming sync IPC from WebProcess when waiting for a sync IPC reply from it
https://bugs.webkit.org/show_bug.cgi?id=189927

Reviewed by Geoffrey Garen.

UIProcess should process incoming sync IPC from WebProcess when waiting for a sync IPC reply from it
in order to avoid deadlocks. This is not an issue currently because the WebProcess does process
incoming sync IPC when waiting for a sync IPC reply. However, we plan to change this in the future
in order to avoid bugs caused by re-entering WebCore at unsafe times.

The reason the UIProcess previously did not do out of order sync IPC process was to avoid processing
a synchronous policy decision IPC for a frameID it did not know about yet, due to the DidCreateMainFrame /
DidCreateSubframe IPC messages being asynchronous. To address this issue, the decidePolicyForNavigationActionSync
IPC handler now calls didCreateMainFrame() / didCreateSubframe() as needed if it does not know about
the frame yet. Note that synchronous policy decisions are rare and are currently only needed by initial
about:blank and fragment navigations.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didCreateMainFrame):
(WebKit::WebPageProxy::didCreateSubframe):
(WebKit::WebPageProxy::decidePolicyForNavigationActionAsync):
(WebKit::WebPageProxy::decidePolicyForNavigationAction):
(WebKit::WebPageProxy::decidePolicyForNavigationActionSync):
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in:
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction):

* WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::createWithCoreMainFrame):
(WebKit::WebFrame::createSubframe):
Drop DispatchMessageEvenWhenWaitingForSyncReply SendOption when sending the
DidCreateMainFrame / DidCreateSubframe IPC. Previously, this SendOption has
no effect because the IPC::Connection would have the
m_onlySendMessagesAsDispatchWhenWaitingForSyncReplyWhenProcessingSuchAMessage
flag set to true. However, now that we stop setting this flag on the IPC
connection from the WebProcess to the UIProcess, it would lead to those
IPC messages getting processed out of order with regards to the
DecidePolicyForNavigationAsync asynchronous IPC. DidCreateMainFrame would
sometimes get processed *after* the DecidePolicyForNavigationAsync IPC
and we would not know about the frameID yet.

* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeConnection):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@236512 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/WebPageProxy.cpp
Source/WebKit/UIProcess/WebPageProxy.h
Source/WebKit/UIProcess/WebPageProxy.messages.in
Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
Source/WebKit/WebProcess/WebPage/WebFrame.cpp
Source/WebKit/WebProcess/WebProcess.cpp