Chrome for iOS uses a file-based session restoration approach for cases where [WKWebView setInteractionState:] cannot be used. These cases include syncing tabs across devices, reopening closed tabs (i.e., where the user closes a tab, but decides later that they want the tab back), and users upgrading from iOS 14. Network requests in such tabs should be marked as non-app-initiated, but there's currently no way to set request attribution for file requests. The result is that all back/forward and link-tap navigations in such tabs get marked as app-initiated, until the next call to [WKWebView loadRequest:] (in practice, this means that all navigation is marked as app-initiated until the next time the user types a URL in the URL bar instead of tapping on links). Specifically: 1) [WKWebView loadFileRequest:allowingReadAccessToURL:] only looks at the URL in the given request, and ignores everything else, including the request's |attribution| property. 2) [WKWebView loadFile:allowingReadAccessToURL:] doesn't have any way to set attribution.
<rdar://problem/84824703>
This sounds like a bug: [WKWebView loadFileRequest:allowingReadAccessToURL:] The NSURLRequest passed to this load argument, along with the attribution for that request, should be honored by the system. Let me look into this.
Created attachment 443142 [details] Patch
Comment on attachment 443142 [details] Patch r=me, though EWS might be having some issues.
Created attachment 443144 [details] Patch
Thanks! I think this patch should fix mac EWS, let's see...
Committed r285208 (243834@main): <https://commits.webkit.org/243834@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 443144 [details].