Bug 232506 – [iOS] Need API for marking file requests as non-app-initiated

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Ali Juma]

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.

[Radar WebKit Bug Importer]

<rdar://problem/84824703>

[Brent Fulgham]

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.

[Kate Cheney]

Created attachment 443142 [details]
Patch

[Brent Fulgham]

Comment on attachment 443142 [details]
Patch

r=me, though EWS might be having some issues.

[Kate Cheney]

Created attachment 443144 [details]
Patch

[Kate Cheney]

Thanks! I think this patch should fix mac EWS, let's see...

[EWS]

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].