Re: [whatwg] Proposal: navigator.launchURL

Hi!

On 7/14/14, 7:42 PM, "Ian Hickson" <ian@hixie.ch> wrote:


>On Sun, 13 Jul 2014, Adam Barth wrote:
>>
>> == Use Case ==
>> 
>> A web site wants to launch an external protocol handler.  For example,
>> a web site might want to launch PuTTY via the "ssh" scheme.
>
>window.open('ssh://...');
>
>I'll look at this in more detail in due course, but FWIW this appears to
>be more or less identical to a proposal from Microsoft about 18 months
>ago:
>
>   https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799

>
>It's still not really clear what difference this API would have to
>window.open(), though.

How would the window.open(url, name, features) API behave? Here’s what I
imagine:

* If a native application is registered as a protocol handler, no popup
opens but the user is being asked whether to launch that application
(using the currently existing browser dialog - such dialogs exist in
Chrome, FF, IE currently). If the user confirms the dialog, the native
application is launched.

* If a web page registered a protocol handler (through web intents?), that
opens the registered web page in a popup window. Wouldn’t a tab be a
better default here? Is there a “feature” parameter that we can pass to
make this a tabbed window for that?
* If neither native application nor web intent is registered for this, no
popup opens.

Would launching native applications be subject to popup blocking? (I hope
not)

window.open returns a window object.

I guess for web-intents, the usual cross-domain policies apply to the
returned window object.

What should be returned when launching a native application? A window
object wouldn’t make sense. Returning a promise here seems like a weird
API...

As a future user of this API, I would really like to have some feedback
whether or not the launched scheme is registered. The reason is simply to
provide a good user experience: If nothing is able to handle the url
scheme, the web page needs to display completely different UI than if
launching the application worked. I am aware of the privacy issues but I
think Microsoft made a good compromise when coming up with their launchUri
API: Using this API to “fingerprint” installed application is really
intrusive and annoying, and has the risk of the web page losing focus. I
believe that should detract from abusing it. (Furthermore, it should be
disallowed by iframe sandboxing to if iframed third-party ads start
abusing it)

This is why I would favor a new API navigator.launchUri(url) that returns
a promise. The promise would resolve if a handler is registered launching
was allowed by the user. For native applications, it would resolve to
null; for web intents it would resolve to the resulting window object. If
no handler was registered or the user rejected launching an external
application, the promise would be rejected. If opening an external window
for web intents got blocked by a popup blocker, the promise would be
resolved when the user allows the popup. Clean and simple.

What do you think?

Cheers,
Kosta

Received on Tuesday, 15 July 2014 14:30:38 UTC