NEW 158496
WKWebView should expose API for disabling/enabling navigating Universal Links to native applications
https://bugs.webkit.org/show_bug.cgi?id=158496
Summary WKWebView should expose API for disabling/enabling navigating Universal Links...
michaeldo
Reported 2016-06-07 14:53:30 PDT
Summary: There are situations when applications do not want Universal Links to be handled by the System, but prefer the link to be opened in the WKWebView itself. For example, when using a WKWebView in a "private browsing" mode as specified by [WKWebsiteDataStore nonPersistentDataStore], the hosting WKWebView application should be able to prevent opening the Universal Link from opening the native application. Steps to Reproduce: 1. Install and log into the LinkedIn app 2. Create WKWebView with [WKWebsiteDataStore nonPersistentDataStore] 3. Navigate to search engine and search for a LinkedIn user's profile 4. Click on the user's profile Expected Results: Application should be able to disable the system opening the LinkedIn app. Actual Results: LinkedIn app is launched, user unexpectedly looses private context. Version: iOS 9.3.2 (13F69) radar://26683207
Attachments
Patch (4.54 KB, patch)
2019-02-15 11:48 PST, michaeldo
michaeldo: review?
michaeldo
Comment 1 2019-02-15 11:48:58 PST
michaeldo
Comment 2 2019-02-19 23:43:28 PST
achristensen@, please take a look. This was the suggested method to support blocking universal links from opening native applications when a user is within a "private" browsing mode. Thank you!
Alex Christensen
Comment 3 2019-02-20 10:10:49 PST
This is absolutely the approach I suggested, and I think it looks good. However, adding private functions won't help you. We will have to do the internal process to get new public API approved, which will not be documented in Bugzilla. This patch gives us a starting point, though. Thanks!
michaeldo
Comment 4 2019-02-20 10:40:07 PST
Yes,, they would need to be made public. No problem, please let me know if there is anything I can do to help. Thank you for taking a look! (Should I follow up on submitting this change or will it remain in this state and just be replicated later on if the internal processes approves a public version?)
Maciej Stachowiak
Comment 5 2020-02-19 01:52:21 PST
I think it would be a more flexible design to control this through a delegate method. Perhaps decidePolicyForNavigationAction can make the choice? That way, apps could decide on a case by case basis whether to open a webpage inline or open an associated app. Poking around, it seems there is already a private _WKNavigationActionPolicyAllowWithoutTryingAppLink which would continue the navigation without trying universal links. I suspect making that public is the right approach.
Eugene But
Comment 6 2020-02-25 15:30:16 PST
Thanks! Making _WKNavigationActionPolicyAllowWithoutTryingAppLink public works for Chrome.
Note You need to log in before you can comment on or make changes to this bug.