Bug 255863

Created attachment 466063 [details]
Xcode project which acts as a reduced WKWebView test case

I work on an iOS app which has enabled App-Bound domains for the main domain so that we can use ServiceWorker and user script injection when viewing content. It has been reported that a significant number of adverts in iframes cannot be clicked on successfully - instead, the console shows a "Ignoring user script injection for non-app bound domain." error.

I've managed to boil down the problem to the following combination of factors:
1) App-Bound domains are enabled on a WKWebView in an iOS app running on iOS 14 and above (up to and including at least iOS 16.4.1)
2) The App implements `webView(_:createWebViewWith:for:windowFeatures:)` to support `<a target="_blank">`, `window.open`, etc
3) A webpage on an App-Bound domain is loaded in the webview
4) The App-Bound page contains an iframe which has a domain which is not App-Bound
5) The iframe contains a link which uses `javascript:window.open(...)`

Under these circumstances, the `WKUIDelegate` method should be called so that either a window can be opened or the navigation can be handled differently (SFSafariViewController, system browser, etc). However it is not: instead, "Ignoring user script injection for non-app bound domain." is logged and the action is blocked.

I believe this action should work, because https://webkit.org/blog/10882/app-bound-domains/ says "... Note that the check for app-bound domains only occurs for the top-level frame, so ShopApp will still be able to display third party iframes from domains outside the app-bound set on shop.example." and this is backed up by https://bugs.webkit.org/show_bug.cgi?id=211815 . Using a semantic link with a `target="_blank"` attribute also *does* work correctly, invoking the WKUIDelegate method as expected; it appears this bug is a combination of the `javascript:` URL in use within the iframe and the app-bound domain.

(I've found that a workaround is to add the iframe domain to the App-Bound domains list - the `javascript:` links then work. However I don't believe this should be necessary; in our case it'd also probably not work fully, because ads may be served from a variety of domains not under our control. I have checked with the ad vendors and `javascript:window.open(...)` is also apparently a common approach in ads templates and migrating them all to actual semantic links isn't workable!)

I was also a little surprised that WKUIDelegate methods (and WKNavigationDelegate methods such as `webView(_:decidePolicyFor:decisionHandler:)`) can trigger App-Bound warnings - this isn't mentioned on https://webkit.org/blog/10882/app-bound-domains/ which still seems to be the best available documentation for App-Bound domains, but thinking about it it does make complete sense they are covered! This may just be a documentation task.

I attach a reduced test case Xcode project that reproduces the problem with two tiny webpages for easy debugging.