Bug 158496 - WKWebView should expose API for disabling/enabling navigating Universal Links to native applications
Summary: WKWebView should expose API for disabling/enabling navigating Universal Links...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: Other
Hardware: iPhone / iPad iOS 12
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-06-07 14:53 PDT by michaeldo
Modified: 2020-02-26 17:53 PST (History)
8 users (show)

See Also:


Attachments
Patch (4.54 KB, patch)
2019-02-15 11:48 PST, michaeldo
michaeldo: review?
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.