Re: [whatwg] Proposal: navigator.launchURL

Hi!

On 7/14/14, 7:40 AM, "Michael[tm] Smith" <mike@w3.org> wrote:
>Adam Barth <w3c@adambarth.com>, 2014-07-13 22:30 -0700:
>>On Sun, Jul 13, 2014 at 8:05 PM, Michael[tm] Smith <mike@w3.org> wrote:
>>> It proposed a method that includes a "successCallback" &
>>>"noHandlerCallback":
>>>   navigator.launchUri(uri, successCallback, noHandlerCallback)
>>No, I missed that.  Looks very similar.  A more modern idiom would be
>>to return a promise to inform the caller of success or failure.

We modeled this proposal roughly after the msLaunchUri API introduced in
Windows 8 for IE:
(The docs say that this is IE 10+, but it’s actually Windows 8+)
http://msdn.microsoft.com/en-us/library/ie/jj154912(v=vs.85).aspx


>>Is there a use case for reporting success or failure?  I thought about
>>including that, but it wasn't necessary for the use cases I'm aware
>>of.

>Konstantin mentioned:
>>> We would like to have a stable, well-defined API for this that also
>>>allows
>>> to handle the “user declined / protocol handler is not installed” case
>>> gracefully. As an example, the web page could show a UI to tell the
>>>user
>>> how to install an SSH client.
>http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0797.html



Yes, the success/failure callback are very important to have a good user
experience. Most important is whether the information that handler is not
available (so that you can e.g. provide a download to install the
application instead). Having a success callback is very nice to provide a
good UX.

In the end, it’s a privacy tradeoff: Do you want to mix “handler not
available” and “user declined the launch” into one callback, so that the
web page does not know whether X is installed or the user just didn’t want
to launch it? (However, that information might be accessible from the
timings…)

What the msLaunchUri call does:
* successCallback if the app was launched
* noHandlerCallback if no URI handler was installed
* if you get no callback that means either the user declined the launch or
has not click anything yet (if there was a confirmation dialog).

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.

I’m not decided on promises vs. callbacks. I guess promises are the more
modern approach. Either would work fine here and it’s easy to wrap one
into the other if needed.

Anne van Kesteren asked:

> Is this observably different from
> <a target=_blank rel=noreferrer>
> somehow?


(Sorry for moving this mail into here, but I wasn’t subscribed to whatwg
when the question was asked so I don’t have access to it to reply to it
regularly)

There are two very big differences:
1. The web pages doesn’t know whether launching works (UX issue, see above)
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).

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)
* Chrome/Android shows a blank “not found” page with the custom URI in the
navigation bar (on this platform, using intent: links is recommended to
launch custom URL schemes / open to Google Play store if the app is not
installed)
* 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)
* Firefox Android shows an error dialog
* Safari/Mac asks to look on the Mac App Store for it (bad if the
application is not on the app store)
* Safari/iOS ignores it and users stays on the page (good) (Same for
Chrome/iOS)
* IE shows some error message
* IE on Windows RT/Windows Phone 8 asks to look in the Windows Store

So all in this is a huge mess to work with :) That’s why a standardized
API would be a very neat thing!

Also, note that most pages using custom URI schemes have some weird way to
detect whether or not the custom URI scheme is installed to work around
this issue. For example, the iTunes pages check whether some Apple plugin
is available that comes bundled with iTunes (on Windows/Mac). (On iOS,
they assume the “App Store” app is installed, of course)

Boris Zbarsky asked:
> Which raises a separate question, by the way: should a sandboxed iframe
> (without allow-popups, in case that matters) be able to do this?

(Again, sorry to move your question in here, same reason as for Anne)

I think it should be allowed in sandboxed iframes (but maybe I’m biased as
I want to use this API). At the very least, there should be a sandbox
attribute that allows using this API.



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 13:48:28 UTC