Fix deeplink logic

[data-sync-user]

Deeplinks from within the webview are not handled correctly today.

If the user is in private browsing the app should never deeplink to an external application.

If the user is in regular browsing mode the user should first be prompted with a dialog asking if they would like to go to the external application. Then if they select yes the app should open the external application. If they select no the url should be loaded in the webview directly.

Some changes are needed in the logic within the navigation delegate method to support this.

func webView(
        _ webView: WKWebView,
        decidePolicyFor navigationAction: WKNavigationAction,
        decisionHandler: ((WKNavigationActionPolicy) -> Void)
    )

This can be achieved by using both canOpenURL and open(_:options:completionHandler

Otherwise default to:

decisionHandler(.cancel)
webView.load(navigationAction.request)

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ Orla Mitchell commented:

Daniela Arcese Can you confirm the behaviour I’ve outlined in this ticket is how we should handle deeplinks that are triggered from within the webview?

This popped up in relation to an issue with some tracking around Fakespot and has also popped up in several bugs recently around private browsing. So I’ve created this ticket to address the underlying cause and want to be sure the behaviour it’s targeting is correct before moving forward.

[data-sync-user]

➤ Daniela Arcese commented:

Orla Mitchell yes that’s correct, thanks for checking.

[data-sync-user]

➤ Matthew Reagan commented:

Orla Mitchell Thought I would take a look at this but there’s a few aspects I’m not 100% clear on; is there any chance we could sync up at some point so I could ask a couple questions?

[data-sync-user]

➤ Daniela Arcese commented:

Matthew Reagan what is the status of this?

[data-sync-user]

➤ Matthew Reagan commented:

Daniela Arcese I’m happy to look into this but would need some additional clarification on the action items, I’m not 100% clear on the expected implementation details. Can we possibly update the ticket with specific steps and actual-vs-expected behaviors for this task? I think that would be helpful.

(+cc tech team: Laurie Marceau or Yoana Rios Diaz might already be working in related code)

[data-sync-user]

➤ Sorin Paraipan commented:

*Note for QAs when testing: In normal browsing, the deeplinks should open in their respective app, if installed. In private browsing, the deeplinks should always open in Firefox.

[data-sync-user]

➤ Alina Moldovan commented:

Validated this issue using both v125 (40222) and v9000 (40232)

Confirming that the issue still reproduces in both cases

!Skype_Video27.mp4|width=888,height=1920,alt="Skype_Video27.mp4"!