Bug 1251507 - Safari parity for url and scheme handling

[st3fan]

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

[thebnich]

But only if a search query is present.

That's not a particularly robust test since "a regular page on maps.apple.com" could easily contain a query, too. With some experimentation, I found that any query on the root maps.apple.com (e.g., http://maps.apple.com/?foo=bar) will be blank, yet any query with a path (e.g., https://www.apple.com/ios/maps/?foo=bar) will not. It's still hacky, but that means you could harden the test a bit more by also checking that the path is empty.