| Summary: | Regression (iOS 13.4, r249142): WKWebView.loading is never reset after a Back navigation in an iframe | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Ali Juma <ajuma> | ||||||
| Component: | Page Loading | Assignee: | Alex Christensen <achristensen> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | achristensen, beidson, cdumez, cgarcia, ggaren, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
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. Created attachment 399506 [details]
Patch
Comment on attachment 399506 [details]
Patch
r=me
Committed r261761: <https://trac.webkit.org/changeset/261761> All reviewed patches have been landed. Closing bug and clearing flags on attachment 399506 [details]. |
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.