Re: [whatwg] Proposal: navigator.launchURL

Hi Anne!


On 7/14/14, 4:44 PM, "Anne van Kesteren" <annevk@annevk.nl> wrote:

>On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke
><Konstantin.Welke@citrix.com> wrote:
>> How we use it:
>> * We try to launch our native application using a custom URI scheme
>> * If successful, we show some “success” UI
>> * If no handler installed, the user gets a download
>> * If we don’t get a callback (= user declined or undecided), the user
>>can
>> choose between trying again and downloading the application.
>
>This does not seem particularly compelling. I'd rather figure out why
>there needs to be a native application in the first place.

Well as long as web pages are not as powerful as web apps, there’s reasons
to start external applications for some functionality.

The SSH client is an easy example, unless we allow web pages to connect to
arbitrary hosts and ports (implementing SSH is still not possible with
WebRTC, right?). Another example, Apples uses a custom URI scheme to
launch iTunes, which can e.g. sync with iPhones over USB and/or WiFi -
which I don’t see as a web app in the foreseeable future. At Citrix, this
is also used to launch native applications for functionality not
implementable as a web app (e.g. screen sharing session that transmits a
Windows UAC dialog or installing a Windows Service).

>> Anne van Kesteren asked:
>>> Is this observably different from
>>> <a target=_blank rel=noreferrer>
>>> somehow?
>>
>> There are two very big differences:
>> 1. The web pages doesn’t know whether launching works (UX issue, see
>>above)
>
>The privacy implications seem somewhat tricky. Although since the user
>first has to go through some UI, it might not be too bad.

Yes, this is also the reason why I favor a launchUri() call over a
isProtocolRegistered() call. This way, if a web page abuses the API it
will be more annoying to the user. It is the web page’s self-interested
not to annoy the user too much.

>> 2. Browser behavior if the URI scheme is not registered varies wildly.
>>If
>> we implement such a launchURL or launchUri call, we can specify this
>> behavior (as Microsoft did for msLaunchUri, see msdn link above).
>
>This seems like something we need to fix either way. We should have
>this navigation behavior nailed down.

I agree. However it is easier for JavaScript to check whether e.g.
navigator.launchUri exists and assume it behaves correctly if it exists.
Using a plain link, JS would need to detect whether this is one of the
browsers that implement launching external apps “as specified” . Also, a
plain link can’t return a promise  (if we can agree on this kind of
feedback).

>> As an example, what browsers currently do when trying to launch an
>> unregistered URI scheme:
>> * Chrome/Desktop ignore it completely (good behavior) (same for Opera
>> these days)
>
>Is this when you target <iframe> or in general?

For Chrome/Desktop, this seems to be the case in general. Here’s a test
page that provides 3 ways of launching “nonexistent://foo.bar” (which I
hope is not registered for an external application anywhere):
http://lastpageofthe.net/nonexistent.html


Note that for other browsers, the behavior usually varies between iframe,
plain link and setting document.location. E.g. I just re-tested with
Firefox/Mac and it shows an empty web page with the custom URI in the
navigator bar for the plain link as well as when setting
document.location. However, when using an iframe, a JS exception appears
in the JS logs and no user-visible UI.

>> * Firefox/Desktop shows a dialog asking the user to choose the
>>application
>> to handle these URIs with (this is ok for some cases like ssh://, but in
>> the worst case the user can really misconfigure their browser here)
>
>What is a worst case?

If the user chooses an application that cannot handle the protocol and
checks “Remember my choice”, Firefox will always launch the wrong
application without further prompting the user. This can be fixed in the
Firefox settings, but is hard to figure out for the user.

However, at least from superficial testing it seems that Firefox changed
their behavior and now simply ignore unknown protocols when they are being
launched via iframe.

-- 
Cheers,

Konstantin Welke
Senior Software Developer
Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe
http://www.citrixonline.com <http://www.citrixonline.com/>

Work better. Live better.
Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe
Geschäftsführer: Tommy Ahlers | David Zalewski | Michael DiFilippo
Sitz der Gesellschaft: Karlsruhe | Registergericht: Amtsgericht Mannheim
HRB 713721
Citrix Online UK Ltd <http://www.citrixonline.com/imprint-en.tmpl>

Received on Monday, 14 July 2014 15:26:58 UTC