Assert in WebPageProxy::suspendCurrentPageIfPossible()
authorcdumez@apple.com <cdumez@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 11 Mar 2019 23:31:23 +0000 (23:31 +0000)
committercdumez@apple.com <cdumez@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 11 Mar 2019 23:31:23 +0000 (23:31 +0000)
commitcbc89ace0f659e2074c9529d235f9df3897a76c2
treeaea3275d795eadce9d760fde1da14e790e77c83b
parent4f0e68f0c2f25d20197d1eff48319773b8637eb4
Assert in WebPageProxy::suspendCurrentPageIfPossible()
https://bugs.webkit.org/show_bug.cgi?id=195506
<rdar://problem/48733477>

Reviewed by Alex Christensen.

Source/WebKit:

The crash was caused by the top-hit preloading logic in MobileSafari which creates a new Web view that is *related*
to the previous one, restores the session state onto it and then triggers a load in this new Web view.

Initially, the 2 Web views use the same process as they are related. However, if the new load's URL is cross-site
with regards to the first view's URL, then we decide to process swap in the new view. This process swap makes
sense from a security standpoint. However, when we commit the load in the new process and call
suspendCurrentPageIfPossible() we end up in an unexpected state because we have a fromItem (due to the session
state having been restored on the new view) but we haven't committed any load yet in this new view.

To address the issue, suspendCurrentPageIfPossible() now returns early and does not attempt to suspend anything
if we have not committed any load yet.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::suspendCurrentPageIfPossible):
Do not attempt to suspend to current page if we have not committed any provisional load yet.

Tools:

Add API test coverage.

* TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242755 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/WebPageProxy.cpp
Tools/ChangeLog
Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm