This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
How does this differ from window.open()?
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.
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.)
The main goal is to know for sure if the scheme handler isn't present so that you can do something instead.
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).
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.
(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?
(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.
This function should return a Promise rather than taking a success and a failure callback.
Making this a higher priority to actively seek more feedback on from implementers and webdevs.
HTML5.1 Bugzilla Bug Triage: This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).