Re: [whatwg] Proposal: navigator.launchURL

On Mon, Jul 14, 2014 at 12:35 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Jul 14, 2014 at 4:26 AM, Adam Barth <w3c@adambarth.com> wrote:
>> The launchURL() method requests that the User Agent launch the
>> protocol handler for the specified URL.  If the User Agent itself is
>> the registered protocol handler for |url|, then the User Agent should
>> open the requested URL in a new browsing context in a new unit of
>> related browsing contexts.
>
> Is this observably different from
>
>   <a target=_blank rel=noreferrer>
>
> somehow?

Yes, that causes a blank window to be created before launching the
external protocol handler.

On Mon, Jul 14, 2014 at 4:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Which raises a separate question, by the way: should a sandboxed iframe
> (without allow-popups, in case that matters) be able to do this?

Nope, I think we should block that.


On Mon, Jul 14, 2014 at 6:47 AM, Konstantin Welke
<Konstantin.Welke@citrix.com> wrote:
> 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.

Makes sense.

> 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).

If the user declines, we should probably reject the promise.

> 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.

Promises are the future.  New APIs should use them instead of having a
pair of success and failure callbacks.

> 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.

IMHO, the allow-popups should enable the feature, just like it enables
window.open.

On Mon, Jul 14, 2014 at 7:44 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> This does not seem particularly compelling. I'd rather figure out why
> there needs to be a native application in the first place.

It's about user choice.  Users might choose to use a web-based SSH
client or they might choose to use a native application as their SSH
client.  The web site that's launching the SSH session doesn't need to
care.  They can all share the same URI scheme: ssh.

Adam

Received on Monday, 14 July 2014 16:51:32 UTC