Re: [whatwg] Proposal: navigator.launchURL

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; annevk@annevk.nl; bzbarsky@MIT.EDU
Cc: whatwg@whatwg.org; Ben Johnson
Subject: 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 17:39:53 UTC