Hey all,

I'm just back from leave and catching up on responses, but I think my colleague 
Kosta responded with most of our concerns.

Re: promises:

Yes, I think this is pretty clearly an appropriate place for them. They aren't 
there now because:

a) The initial draft was pretty much just a port of the IE API to open a 
discussion.
b) I was unsure of the current status of promises for new proposals; I now 
understand they're expected at this point in time.

Cheers,
Ben

-----Original Message-----
From: Konstantin Welke 
Sent: Monday, July 14, 2014 6:48 AM
To: Michael[tm] Smith; Adam Barth; ann...@annevk.nl; bzbar...@mit.edu
Cc: wha...@whatwg.org; Ben Johnson
Subject: Re: [whatwg] Proposal: navigator.launchURL

Hi!

On 7/14/14, 7:40 AM, "Michael[tm] Smith" <m...@w3.org> wrote:
>Adam Barth <w...@adambarth.com>, 2014-07-13 22:30 -0700:
>>On Sun, Jul 13, 2014 at 8:05 PM, Michael[tm] Smith <m...@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>

Reply via email to