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.
<rdar://problem/51319450>
This still reproduces in iOS 15.2.