Re: [whatwg] Proposal: navigator.launchURL
Hi! On 7/16/14, 1:24 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 15, 2014 at 12:28 AM, Ian Hickson i...@hixie.ch wrote: Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. It seems there are some potential differences: Ian and Adam, what do you think about the points raised by Anne and me? For the window.open approach that you proposed, how would the API look like? What would the API return if an external app was launched? Cheers, Kosta -- 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
Re: [whatwg] Proposal: navigator.launchURL
On Tue, Jul 15, 2014 at 12:28 AM, Ian Hickson i...@hixie.ch wrote: They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. It seems there are some potential differences: * You cannot detect if window.open() failed (e.g. the user declined to open the application or the browser failed to find an application) * If the scheme is mapped to an http/https URL it is unclear: ** whether you get a new top-level browsing context or if you get an auxiliary browsing context (i.e. what window.opener return?) ** if a referrer is included ** if credentials are included And the open question for those is whether those differences are desirable and should perhaps be configurable. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.launchURL
Hi!
On 7/14/14, 7:42 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at this in more detail in due course, but FWIW this appears to
be more or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
How would the window.open(url, name, features) API behave? Here’s what I
imagine:
* If a native application is registered as a protocol handler, no popup
opens but the user is being asked whether to launch that application
(using the currently existing browser dialog - such dialogs exist in
Chrome, FF, IE currently). If the user confirms the dialog, the native
application is launched.
* If a web page registered a protocol handler (through web intents?), that
opens the registered web page in a popup window. Wouldn’t a tab be a
better default here? Is there a “feature” parameter that we can pass to
make this a tabbed window for that?
* If neither native application nor web intent is registered for this, no
popup opens.
Would launching native applications be subject to popup blocking? (I hope
not)
window.open returns a window object.
I guess for web-intents, the usual cross-domain policies apply to the
returned window object.
What should be returned when launching a native application? A window
object wouldn’t make sense. Returning a promise here seems like a weird
API...
As a future user of this API, I would really like to have some feedback
whether or not the launched scheme is registered. The reason is simply to
provide a good user experience: If nothing is able to handle the url
scheme, the web page needs to display completely different UI than if
launching the application worked. I am aware of the privacy issues but I
think Microsoft made a good compromise when coming up with their launchUri
API: Using this API to “fingerprint” installed application is really
intrusive and annoying, and has the risk of the web page losing focus. I
believe that should detract from abusing it. (Furthermore, it should be
disallowed by iframe sandboxing to if iframed third-party ads start
abusing it)
This is why I would favor a new API navigator.launchUri(url) that returns
a promise. The promise would resolve if a handler is registered launching
was allowed by the user. For native applications, it would resolve to
null; for web intents it would resolve to the resulting window object. If
no handler was registered or the user rejected launching an external
application, the promise would be rejected. If opening an external window
for web intents got blocked by a popup blocker, the promise would be
resolved when the user allows the popup. Clean and simple.
What do you think?
Cheers,
Kosta
Re: [whatwg] Proposal: navigator.launchURL
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? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.launchURL
On 7/14/14, 3:35 AM, Anne van Kesteren wrote: Is this observably different from a target=_blank rel=noreferrer somehow? I think for a sandboxed iframe it might be... Which raises a separate question, by the way: should a sandboxed iframe (without allow-popups, in case that matters) be able to do this? -Boris
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
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke konstantin.we...@citrix.com wrote: 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. This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. Anne van Kesteren asked: Is this observably different from a target=_blank rel=noreferrer somehow? There are two very big differences: 1. The web pages doesn’t know whether launching works (UX issue, see above) The privacy implications seem somewhat tricky. Although since the user first has to go through some UI, it might not be too bad. 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). This seems like something we need to fix either way. We should have this navigation behavior nailed down. 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) Is this when you target iframe or in general? * 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) What is a worst case? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.launchURL
Hi Anne! On 7/14/14, 4:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke konstantin.we...@citrix.com wrote: 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. This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. Well as long as web pages are not as powerful as web apps, there’s reasons to start external applications for some functionality. The SSH client is an easy example, unless we allow web pages to connect to arbitrary hosts and ports (implementing SSH is still not possible with WebRTC, right?). Another example, Apples uses a custom URI scheme to launch iTunes, which can e.g. sync with iPhones over USB and/or WiFi - which I don’t see as a web app in the foreseeable future. At Citrix, this is also used to launch native applications for functionality not implementable as a web app (e.g. screen sharing session that transmits a Windows UAC dialog or installing a Windows Service). Anne van Kesteren asked: Is this observably different from a target=_blank rel=noreferrer somehow? There are two very big differences: 1. The web pages doesn’t know whether launching works (UX issue, see above) The privacy implications seem somewhat tricky. Although since the user first has to go through some UI, it might not be too bad. Yes, this is also the reason why I favor a launchUri() call over a isProtocolRegistered() call. This way, if a web page abuses the API it will be more annoying to the user. It is the web page’s self-interested not to annoy the user too much. 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). This seems like something we need to fix either way. We should have this navigation behavior nailed down. I agree. However it is easier for JavaScript to check whether e.g. navigator.launchUri exists and assume it behaves correctly if it exists. Using a plain link, JS would need to detect whether this is one of the browsers that implement launching external apps “as specified” . Also, a plain link can’t return a promise (if we can agree on this kind of feedback). 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) Is this when you target iframe or in general? For Chrome/Desktop, this seems to be the case in general. Here’s a test page that provides 3 ways of launching “nonexistent://foo.bar” (which I hope is not registered for an external application anywhere): http://lastpageofthe.net/nonexistent.html Note that for other browsers, the behavior usually varies between iframe, plain link and setting document.location. E.g. I just re-tested with Firefox/Mac and it shows an empty web page with the custom URI in the navigator bar for the plain link as well as when setting document.location. However, when using an iframe, a JS exception appears in the JS logs and no user-visible UI. * 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) What is a worst case? If the user chooses an application that cannot handle the protocol and checks “Remember my choice”, Firefox will always launch the wrong application without further prompting the user. This can be fixed in the Firefox settings, but is hard to figure out for the user. However, at least from superficial testing it seems that Firefox changed their behavior and now simply ignore unknown protocols when they are being launched via iframe. -- 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
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 5:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke konstantin.we...@citrix.com wrote: 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. This does not seem particularly compelling. I'd rather figure out why there needs to be a native application in the first place. As a person working for a company with a big mobile game catalogue, I'd say this is a reality and happening already, and unfortunately I've seen this currently done in some pretty gross, uninteroperable and user-hostile ways and would love to see those go away. If we specify the way this should be done, this will also let the UA be more aware of what the web app is trying to do, so for people like me who hate websites trying to open an app, the UA could have an option to always reject these attempts. I think the overall compelling thing here is providing a good UX for something that may or may not be a good thing, but is happening already, with poor UX. - Jussi
Re: [whatwg] Proposal: navigator.launchURL
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
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; 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
Re: [whatwg] Proposal: navigator.launchURL
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at this in more detail in due course, but FWIW this appears to
be more or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 10:42 AM, Ian Hickson i...@hixie.ch wrote:
On Sun, 13 Jul 2014, Adam Barth wrote:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
window.open('ssh://...');
I'll look at this in more detail in due course, but FWIW this appears to
be more or less identical to a proposal from Microsoft about 18 months
ago:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799
It's still not really clear what difference this API would have to
window.open(), though.
The difference is that window.open opens a new browser window even if
the URL is handled by an external protocol handler. Even if we
changing current browsers to detect whether the URL will be handled by
an external protocol handler before opening the window, web sites
won't be able to feature-detect which browsers have this new behavior
and therefore won't be able to move away from iframe@src hacks until
all the browsers they care about have the behavior change. By
contrast, sites can feature detect navigator.launchURL and fall back
to iframe@src in UAs that lack the new API.
Adam
Re: [whatwg] Proposal: navigator.launchURL
On Mon, 14 Jul 2014, Adam Barth wrote: The difference is that window.open opens a new browser window even if the URL is handled by an external protocol handler. Even if we changing current browsers to detect whether the URL will be handled by an external protocol handler before opening the window, web sites won't be able to feature-detect which browsers have this new behavior and therefore won't be able to move away from iframe@src hacks until all the browsers they care about have the behavior change. By contrast, sites can feature detect navigator.launchURL and fall back to iframe@src in UAs that lack the new API. I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 2:10 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Jul 2014, Adam Barth wrote: The difference is that window.open opens a new browser window even if the URL is handled by an external protocol handler. Even if we changing current browsers to detect whether the URL will be handled by an external protocol handler before opening the window, web sites won't be able to feature-detect which browsers have this new behavior and therefore won't be able to move away from iframe@src hacks until all the browsers they care about have the behavior change. By contrast, sites can feature detect navigator.launchURL and fall back to iframe@src in UAs that lack the new API. I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. If developers don't adopt a feature, browser vendors are less likely to adopt the feature. That's why the bootstrapping process is an important consideration. Adam
Re: [whatwg] Proposal: navigator.launchURL
On Mon, 14 Jul 2014, Adam Barth wrote: I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius It doesn't really matter how long it takes. The time until authors can stop using the iframe hack is the same whether we provide a new API or have a legacy API that needs updating to be slightly less annoying. If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.launchURL
On Mon, Jul 14, 2014 at 3:28 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 14 Jul 2014, Adam Barth wrote: I'm skeptical of features that only have a benefit during a short transition phase. Suppose it's five years from now and now everyone implements window.open() in this cleaner way and everyone also has launchURL(). Why is it good that we have both? You're presupposing a particular series of future events. It's more likely that it will take longer than five years. As an example, we shipped unprefixed support for border-radius in May 2010, and browser support is still only ~85% of traffic: http://caniuse.com/#search=border-radius It doesn't really matter how long it takes. The time until authors can stop using the iframe hack is the same whether we provide a new API or have a legacy API that needs updating to be slightly less annoying. If web developers need to wait for the long tail of browsers to catch up before they can use a feature, they're unlikely to adopt it. They can use window.open() today. It's just that it causes a bit of flicker for now. IMHO the flicker is just a bug we should fix. Introducing a new API that literally doesn't do anything you can't already do is a pretty high cost, IMHO. Ok, we can try the window.open approach first. Adam
Re: [whatwg] Proposal: navigator.launchURL
Adam Barth w...@adambarth.com, 2014-07-13 19:26 -0700:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
[...]
== Proposal ==
partial interface NavigatorContentUtils {
void launchURL(DOMString url);
};
Did you see the similar proposal that came up for discussion back in March?
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg791
http://bengjohnson.github.io/ExternalProtocolSpecification.html
It also used the example of launching an SSH client:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0797.html
It proposed a method that includes a successCallback noHandlerCallback:
navigator.launchUri(uri, successCallback, noHandlerCallback)
--
Michael[tm] Smith http://people.w3.org/mike
Re: [whatwg] Proposal: navigator.launchURL
On Sun, Jul 13, 2014 at 8:05 PM, Michael[tm] Smith m...@w3.org wrote:
Adam Barth w...@adambarth.com, 2014-07-13 19:26 -0700:
== Use Case ==
A web site wants to launch an external protocol handler. For example,
a web site might want to launch PuTTY via the ssh scheme.
[...]
== Proposal ==
partial interface NavigatorContentUtils {
void launchURL(DOMString url);
};
Did you see the similar proposal that came up for discussion back in March?
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg791
http://bengjohnson.github.io/ExternalProtocolSpecification.html
It also used the example of launching an SSH client:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0797.html
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.
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. We can always extend the API with a returned promise in the
future if more use cases arise.
Adam
Re: [whatwg] Proposal: navigator.launchURL
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. Yeah 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 -- Michael[tm] Smith http://people.w3.org/mike
