Bug 158496

Summary: WKWebView should expose API for disabling/enabling navigating Universal Links to native applications
Product: WebKit Reporter: michaeldo
Component: WebKit APIAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: achristensen, andersca, beidson, eugenebut, ggaren, krzysztof.modras, mjs, sam
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: iPhone / iPad   
OS: iOS 12   
Attachments:
Description Flags
Patch michaeldo: review?

Description michaeldo 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
Comment 1 michaeldo 2019-02-15 11:48:58 PST
Created attachment 362139 [details]
Patch
Comment 2 michaeldo 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!
Comment 3 Alex Christensen 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!
Comment 4 michaeldo 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?)
Comment 5 Maciej Stachowiak 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.
Comment 6 Eugene But 2020-02-25 15:30:16 PST
Thanks! Making _WKNavigationActionPolicyAllowWithoutTryingAppLink public works for Chrome.