[Webkit-unassigned] [Bug 198437] New: [PSON] WKBackForwardList's currentItem is wrong when quickly going Forward and Back cross-origin

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=198437

            Bug ID: 198437
           Summary: [PSON] WKBackForwardList's currentItem is wrong when
                    quickly going Forward and Back cross-origin
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: History
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ajuma at chromium.org
                CC: achristensen at apple.com, cdumez at apple.com,
                    justincohen at google.com

Steps to reproduce:
1) Visit instagram.com
2) Visit facebook.com
3) Go Back
4) Go Forward, and then quickly go Back

In step (4), it's crucial to go Back while the Forward navigation is still provisional. In order to reproduce, I had to use the Network Link Conditioner to simulate an Edge network (but others have managed to reproduce without this).

At this point, instagram.com will be loaded and displayed, but the WKBackForwardList's current item is facebook.com. So there's a mismatch between WKWebView.URL (instagram.com) and WKWebView.backForwardList.currentItem.URL (facebook.com). In Safari (on iOS), the result is that the Forward button is greyed out (it should really be active and let us go forward to facebook.com) and tapping on Back just keeps us on instagram.com.

What's going wrong:
In step (4), when we go Back, the WebPageProxy still has an m_provisionalPage for the Forward navigation to facebook.com. We send a WebPage::GoToBackForwardItem IPC to the WebProcess and then receive a WebPageProxy::backForwardGoToItem IPC for the Back navigation to instagram.com, but since m_provisionalPage is non-null, we early out it in WebPageProxy::backForwardGoToItem because we think this is a dummy navigation from a process that's getting suspended. And after that, nothing ever corrects the WebBackForwardList, so it's left in a bad state, with the facebook.com item as the currentItem.

This seems a bit tricky to fix, since the UIProcess doesn't seem to be in a good position to figure out whether the WebPageProxy::backForwardGoToItem IPC is for a dummy navigation or not. Maybe we should change the logic in the WebProcess so that for PolicyDecision::StopAllLoads (that is, for the process swap case), we only update the WebProcess' WebBackForwardListProxy but don't send a WebPageProxy::backForwardGoToItem IPC; then we can remove the early-out in WebPageProxy::backForwardGoToItem. Or, alternatively, include some more information in that IPC about what's triggering it so that we only ignore it when we really should.

A longer-term fix would be to make the UIProcess fully in charge of updating the back/forward list for back/forward navigations (instead of first sending an IPC to the WebProcess and then waiting to receive an IPC back before changing the current item) but that seems like a larger/riskier change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190531/8e7220e3/attachment.html>