- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 14 Jul 2014 16:44:29 +0200
- To: Konstantin Welke <Konstantin.Welke@citrix.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, "bzbarsky@MIT.EDU" <bzbarsky@mit.edu>, "Michael\[tm\] Smith" <mike@w3.org>, Adam Barth <w3c@adambarth.com>, Ben Johnson <Ben.Johnson@citrix.com>
On Mon, Jul 14, 2014 at 3:47 PM, Konstantin Welke <Konstantin.Welke@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/
Received on Monday, 14 July 2014 14:45:03 UTC