1470664 - Firefox iOS is blocking app url scheme navigations (302 redirect or JS)

Status: RESOLVED FIXED

(Firefox for iOS :: Browser, defect, P2)

Description

[Julien Bodet]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

Steps to reproduce:

I have an app using AppAuth (https://github.com/openid/AppAuth-iOS) to perform an OAuth 2 authorization flow. AppAuth supports authorization flow in custom browsers like Firefox.

I tried to perform the authorization flow in Firefox iOS with a custom scheme redirect URI (myapp://) but the redirection to the app is never fired.

I had a look at BrowserViewController+WKNavigationDelegate.swift and I clearly see that it's not supported. Firefox doesn't seem to handle all the custom schemes other Apple maps, App Store, mail-to, etc...


Actual results:

The redirection sent by the server is never performed by Firefox and the browser get stuck.


Expected results:

The redirection should be handled by Firefox and redirect back to the app that initiates the OAuth flow.

Comment 1

[:garvan]

We cancel at the end of the nav delegate: https://github.com/mozilla-mobile/firefox-ios/blob/master/Client/Frontend/Browser/BrowserViewController/BrowserViewController%2BWKNavigationDelegate.swift#L153

I am not sure why we do this nav cancellation. 

I test using medium.com, if you scroll to the bottom of an article a link will appear to open in app, which will be a 'medium://' URL scheme.

Comment 2

[:garvan]

I am raising this to a P2 priority, this is standard iOS browser behaviour that we aren't supporting (Safari, Chome, etc)

Comment 3

[Julien Bodet]

Thank you for your quick answer. I would like to work on a pull request fixing this bug, can I assign this task to me?
Thanks!

Comment 4

[:garvan]

Assigned it to you, can you also check the github history on that function and see if there is a clue as to why it is done this way? Perhaps there is some other bug we have to be careful about by changing this.

Comment 5

[Julien Bodet]

By searching in the history of `WKNavigationDelegate`, I found that bug 1403833 (https://bugzilla.mozilla.org/show_bug.cgi?id=1403833) was fixed by wrapping `UIApplication.shared.openURL(url)` logic in `if navigationAction.navigationType == .linkActivated` (https://github.com/mozilla-mobile/firefox-ios/pull/3376/files).

The purpose of this fix was to avoid showing the "Cannot Open Page" alert when a link is navigated by JavaScript (`window.location = ...`). But it completely prevent `onclick` on a HTML link or `onload` events changing `window.location` to a custom scheme url to work. I noted that both onload and onclick with custom scheme works with Google Chrome.

Instead of letting `UIApplication` opening URLs only for `WKNavigationType.linkActivated` (user action), I propose to remove this condition and show the "Cannot Open URL" message only for `WKNavigationType.linkActivated`. This way if the JavaScript link cannot be opened, it'll fail silently without popping an unexpected message to the user.

What do you think?

Comment 6

[Julien Bodet]

Also I noticed another anormal behaviour when trying to open a deeplink (`<a href="fb://">Click this link</a>`) for the first time with Firefox. Here I try to open facebook app, and it is installed, a system popup appears asking the user to confirm. If he cancels, the "Cannot Open Page" error is shown but it shouldn't it was cancelled by the user. In addition of what I said in the comment above, I would also add a check for `canOpenURL` and show the error message only if it returns false.

Comment 7

[Julien Bodet]

Attachment: System confirmation

Comment 8

[Julien Bodet]

(In reply to Julien Bodet from comment #6)
> Also I noticed another anormal behaviour when trying to open a deeplink (`<a
> href="fb://">Click this link</a>`) for the first time with Firefox. Here I
> try to open facebook app, and it is installed, a system popup appears asking
> the user to confirm. If he cancels, the "Cannot Open Page" error is shown
> but it shouldn't it was cancelled by the user. In addition of what I said in
> the comment above, I would also add a check for `canOpenURL` and show the
> error message only if it returns false.

After a quick check, I realized that this won't work because canOpenURL returns false for all custom schemes not present in LSApplicationQueriesSchemes array of Info.plist.

Comment 9

[:garvan]

Would it be clearer to split this bug into 2 separate bugs:
- Firefox iOS is blocking app url scheme navigations
- Oath 2 app flows broken

Certainly the 2nd issue is dependent on the first one.

Comment 10

[:garvan]

My Comment 1 is incorrect, leading me to misunderstand the bug. Perhaps I tried this on simulator (or perhaps because the link button to open the medium app required multiple taps before it activated). On my device, without the medium app installed, tapping a `medium://` url scheme does:

Firefox: Shows popup 'Open this link [not now | open app store]'

Safari: Shows two popups: 1) Safari cannot open the page, 2) Open this page in App Store?

This is correct behaviour.

Comment 11

[:garvan]

Julien: can you provide steps to repo that use an app in the store? This will help QA.

Comment 12

[Julien Bodet]

1. Firefox is blocking app url schemes only if the link was not activated by the user. This could be either by changing window.location in javascript (including onclik event on a link) or a 302 server redirect (including OAuth Authorization flow). I don't think it makes sense to split the bug into two separates bugs as the issue is the same but for different use cases. Maybe we can rename this issue to have a more generic title.

2. Referring to 1., the medium:// link you tested with is probably using the href value of the html link, so it works fine because its considered as user activated.

3. I don't know any app in the store using Firefox as the OAuth user agent. For OAuth flow, it can be tested with the AppAuth example, as far as you have an identity provider to test with, but I don't it's necessary to test an OAuth flow. It can instead be tested with a simple local server changing location by javascript, I'll provide the HTML/JS code I used to test with the detailed steps.

Comment 13

[:garvan]

(In reply to Julien Bodet from comment #12)
> 1. Firefox is blocking app url schemes only if the link was not activated by
> the user. 

I recall trying to copy Safari on this. Do you know if Safari changed behaviour here?

> 2. Referring to 1., the medium:// link you tested with is probably using the
> href value of the html link, so it works fine because its considered as user
> activated.

Correct, my mistake when reading this bug was trying custom scheme nav briefly with medium.com -I site I knew had a non-js nav for its app scheme- and it didn't activate. When I came back to this issue today, it worked.

Comment 14

[Julien Bodet]

(In reply to :garvan from comment #13)
> (In reply to Julien Bodet from comment #12)
> > 1. Firefox is blocking app url schemes only if the link was not activated by
> > the user. 
> 
> I recall trying to copy Safari on this. Do you know if Safari changed
> behaviour here?

Yes Safari now opens deeplinks loaded by JS with eithe onclick or onlaod events. You can easily test by loading https://julienbodet.github.io/testdeeplinks/index.html in Safari or even Chrome. A deeplink will load first on onload events and then you'll see two links to test href and onclick event.

Comment 15

[Julien Bodet]

> > 2. Referring to 1., the medium:// link you tested with is probably using the
> > href value of the html link, so it works fine because its considered as user
> > activated.
> 
> Correct, my mistake when reading this bug was trying custom scheme nav
> briefly with medium.com -I site I knew had a non-js nav for its app scheme-
> and it didn't activate. When I came back to this issue today, it worked.

I tried too, the link is sometime unresponsive and I had to tap it multiple times to activate it...
medium.com "open app" link is loading two URL, the first one to open app (medium://) and then another one to open App Store (https://itunes.apple.com/...).

I made a pull request implementing what I proposed in comment #5, and I tested the "open app" medium button in both Firefox and Safari with my fix.

For Firefox if the app is not installed I don't see the "Cannot Open Page" error popup, which is good because the link seems to be JS navigated and then the App Store snackbar. If the app is installed, then Medium app opens and when coming back to Firefox the App Store snack bar is showed.

For Safari if the app is not installed, one error message appears saying the medium app link is not supported. And then another similar message appears for the app store link, which is a bug because it should open the App Store. And if Medium app is installed it match Firefox behaviour but with an additional confirmation alert to open app.

Conclusion: As I said in comment #14, Safari has changed its behaviour with custom scheme JS navigated links. Safari now opens these links and more than that, always show an error popup if they can't be opened (event with onload events (bug 1403833)). So if we want to exactly match Safari behaviour we should completely remove the navigationAction.navigationType == .linkActivated condition.

Comment 16

[Julien Bodet]

Attachment: Pull request

Comment 17

[Julien Bodet]

Thanks for the approval, do you know which release is targeted for this bug?

Comment 18

[:garvan]

Next major release will be cut from master, which is scheduled for next month.

Comment 19

[:garvan]

I marked it for 13 (next major) although it might get cherry picked for a minor release sooner if we decide there are enough small fixes to aggregate into a minor update.