1251507 - Implement Safari Parity for Custom Scheme and Special URL Handling

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

We should behave similar to Safari for special URLs like maps.google.com, itunes.apple.com and custom URL schemes like tel:, facetime: and also third party ones like for example twitter:

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Test Matrix:

https://docs.google.com/spreadsheets/d/1Mfyl6Tw1iSjjiH2CvK22oVtGVxMsJc0sdcqNPezM35w/edit#gid=0

Test Page:

http://people.mozilla.org/~sarentz/t/schemes.html

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1576

This patch gives us parity with Safari with regards to custom scheme and url handling. The patch special cases three types of destinations in the following order:

* `tel:`, `facetime:`, `facetime-audio:` - These all trigger a prompt that displays the phone or account number with the option to *Cancel* or to *Call*. Exactly like Safari.
* `http://maps.apple.com`, `http://itunes.apple.com` - These are recognized as URLs that should be opened with `openURL()` so that the native *Maps* and *App Store* apps are triggered.
* `http:`, `https:` - These are opened in *Firefox*

After that, the default is to open the URL with `UIApplication.openURL()` *without* making a call to `canOpenURL()`. This gives us the following behaviour:

* Third-party schemes like `twitter` trigger an iOS provided prompt that says 'Firefox wants to open Twitter` with the option to *Cancel* or *Open*.
* There seems to be a special case built-in `WKWebView` that automatically handles `http://maps.google.com` correctly where it either opens in Firefox or in the native *Google Maps* app if it is installed.
* It correctly handles `mailto:` and `sms:` links, which are opened without prompting in *Mail.app* and *Messages.app*
* It correctly handles internal iOS schemes like `itms-books:` or `videos:` without prompting.

This patch gives us 99% parity with Safari. The only thing that does not work as in Safari are `http://www.youtube.com` links. iOS has traditionally handled those in a special way, opening the native app if present. If we want that same behaviour then we need to add the `youtube:` scheme to our `Info.plist` so that we have the capability to detect if the YouTube app is installed. I think we should wait with this until we have some user feedback.

Test matrix at https://docs.google.com/spreadsheets/d/1Mfyl6Tw1iSjjiH2CvK22oVtGVxMsJc0sdcqNPezM35w/edit#gid=0

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

The test matrix shows what works in Safari, Chrome and Firefox 2.1 and also how things work after this patch is applied. (Firefox Next column)

Comment 5

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I have duped bug 1226644 to this one because this patch makes the 'Open in App' links on http://mobile.twitter.com work. Tapping them switches to the native Twitter app, displaying the same profile or status as you had open in Firefox.

Comment 6

[Brian Nicholson (:bnicholson)]

Comment on attachment 8723923 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1576

Looks great. Nice job on all the testing!

Comment 7

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Will file followup for maps.apple.com based on user feedback.

Comment 8

[James Hugman [:jhugman] [@jhugman]]

Comment on attachment 8723923 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1576

This patch works even better than I was expecting!

Comment 9

[Francesco Lodolo [:flod]]

This PR removes 2 strings:
"This will open in another application"
"Opening %@"

Are they used in v3.0? If we remove them and export v4.0, we won't them available for v3 dot releases.

Comment 10

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Strings have been put back on master and v4.x