On Mon, Jul 14, 2014 at 12:35 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Mon, Jul 14, 2014 at 4:26 AM, Adam Barth <w...@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 <bzbar...@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.we...@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 <ann...@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
