Bug 20799 - launchURI method proposal
launchURI method proposal
Status: NEW
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
All All
: P1 enhancement
: ---
Assigned To: Robin Berjon
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-29 05:15 UTC by Adrian Bateman [MSFT]
Modified: 2015-06-17 05:47 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Bateman [MSFT] 2013-01-29 05:15:46 UTC
Many platforms support applications registering as custom protocol scheme handlers. For example, mailto: is a scheme for mail but often application platforms encourage app-specific schemes for deep-linking within applications.

While it is undesirable to allow web pages to enumerate the available scheme handlers or even probe for their support, we have found it useful for an pages to attempt to navigate to a URI and understand whether it succeeded or failed. This allows pages to either prompt to install the application or to fallback to a, potentially lesser, web-based experience.

In IE10, we implemented launchURI with a vendor prefix to accomplish this and we are interested to know if other vendors might consider supporting this kind of mechanism in their platform. For simplicity we provided callback methods for success and failure but obviously an alternative approach could use an instance object and events.

partial interface Navigator {
  void launchUri(DOMString uri, optional LaunchURICallback successCallback, optional LaunchURICallback noHandlerCallback);
}
callback void LaunchURICallback();

This is documented further here:
http://msdn.microsoft.com/en-us/library/ie/jj154912
Comment 1 Ian 'Hixie' Hickson 2013-01-29 19:33:02 UTC
How does this differ from window.open()?
Comment 2 Adrian Bateman [MSFT] 2013-01-30 22:17:32 UTC
Different browsers do different things with window.open(). For example, window.open("user@example.com") closes the new window in IE and returns null and opens a new tab set to about:blank in Chrome and returns a reference to that tab.

The goal of this API is for the specific scenario where a navigation is not expected.
Comment 3 Ian 'Hixie' Hickson 2013-02-06 21:34:06 UTC
window.open("user@example.com") should just resolve that string as a relative URL to the current page's base URL and open that, as far as I can tell.

My point is how do you know when a navigation is not expected? Should this navigate or not?:

   window.open("mailto:user@example.com")

If you have registered a 'mailto' handler, it should. If your browser has a built-in mail client that renders in a tab, it should. Should this navigate, or not?:

   window.open("http://example.com/test")

If that URL points to a file with a Content-Disposition header, should the tab remain open? (Right now the "Resource handling" step in the spec suggests that it should, but the browser is allowed to close tabs whenever it wants.)
Comment 4 Adrian Bateman [MSFT] 2013-02-06 22:59:33 UTC
The main goal is to know for sure if the scheme handler isn't present so that you can do something instead.
Comment 5 Ian 'Hixie' Hickson 2013-02-08 02:33:20 UTC
Oh. I don't think we'd want to expose that at all, that seems like just more bits for fingerprinting. If we did want to expose it, it seems a more direct API would be a better solution ("isProtocolSupported()" or some such). But in general, I would expect a platform to just support every protocol, and when the user navigates to one that isn't _actually_ supported, the platform offers to look up a handler for it somehow (the same way that e.g. Windows offers to look up what software handles unknown MIME types).
Comment 6 Adrian Bateman [MSFT] 2013-02-08 18:18:32 UTC
The design is explicitly intended to avoid fingerprinting by not providing the answer in the absence of trying to open a URI. This is a common request from customers who want the web site to be able to recommend their handler not a platform provided one. The platform may not know the application for a specific scheme or might suggest one that doesn't satisfy the goals of the page.
Comment 7 Robin Berjon 2013-02-18 13:57:09 UTC
(In reply to comment #6)
> The design is explicitly intended to avoid fingerprinting by not providing
> the answer in the absence of trying to open a URI. This is a common request
> from customers who want the web site to be able to recommend their handler
> not a platform provided one. The platform may not know the application for a
> specific scheme or might suggest one that doesn't satisfy the goals of the
> page.

Looking at your documentation I get the impression that the parts of this that aren't covered are rather close to Web Intents. Is that not the case?
Comment 8 Adrian Bateman [MSFT] 2013-02-18 16:25:23 UTC
(In reply to comment #7)
> Looking at your documentation I get the impression that the parts of this
> that aren't covered are rather close to Web Intents. Is that not the case?

I'm not sure how to judge that. This API is aimed at a problem we see today given the way many platforms promote using custom schemes. It's a simple way to allow a web page to take action based on whether a specific URI was supported by the current platform configuration or not. Might Web Intents do similar things in future? Perhaps.
Comment 9 Adam Barth 2014-07-14 19:25:33 UTC
This function should return a Promise rather than taking a success and a failure callback.
Comment 10 Michael[tm] Smith 2015-06-16 11:38:49 UTC
Making this a higher priority to actively seek more feedback on from implementers and webdevs.