RESOLVED FIXED 211449
Regression (iOS 13.4, r249142): WKWebView.loading is never reset after a Back navigation in an iframe
https://bugs.webkit.org/show_bug.cgi?id=211449
Summary Regression (iOS 13.4, r249142): WKWebView.loading is never reset after a Back...
Ali Juma
Reported 2020-05-05 08:51:41 PDT
Created attachment 398515 [details] Test case Steps to reproduce: 1. Tap on a link in an iframe, that navigates the iframe (rather than the main frame) 2. Go back Expected result: After (2) completes, WKWebView.loading becomes NO Actual result: WKWebView.loading is stuck at YES until the next navigation On Safari on iOS 13.4, this bug causes the blue loading bar to remain visible after (2) is complete.
Attachments
Test case (185 bytes, text/html)
2020-05-05 08:51 PDT, Ali Juma
no flags
Patch (5.74 KB, patch)
2020-05-15 13:33 PDT, Alex Christensen
no flags
Radar WebKit Bug Importer
Comment 1 2020-05-05 09:16:43 PDT
Ali Juma
Comment 2 2020-05-08 13:27:38 PDT
This is happening because PageLoadState::setPendingAPIRequest is called during WebPageProxy::goToBackForwardItem, but the pending API request is never cleared. In WebPageProxy::didStartProvisionalLoadForFrameShared, |navigation| is null, so we don't call PageLoadState::clearPendingAPIRequest. The |navigation| is null because in WebPageProxy::goToBackForwardItem, we only create an API::Navigation if the target item isn't considered same-document wrt the current item. So this bug is a regression from r249142, which changed WebPageProxy::didStartProvisionalLoadForFrameShared to only call clearPendingAPIRequest if |navigation| is non-null.
Alex Christensen
Comment 3 2020-05-15 13:33:26 PDT
Geoffrey Garen
Comment 4 2020-05-15 13:45:05 PDT
Comment on attachment 399506 [details] Patch r=me
EWS
Comment 5 2020-05-15 14:31:25 PDT
Committed r261761: <https://trac.webkit.org/changeset/261761> All reviewed patches have been landed. Closing bug and clearing flags on attachment 399506 [details].
Note You need to log in before you can comment on or make changes to this bug.