Re: [w3c/manifest] Adding protocol handlers (#972)

> > We think it makes a lot of sense to allow a developer to register protocol handlers in the manifest. It is where they will also register file handlers, link handlers and share targets, all in a way that ties them up nicely with the application itself.
> 
> This makes sense, particularly for new types (e.g., share target). There's been hesitancy amongst implementers in the past to duplicate functionality already provided by a JS API. Having said that...
> 
> > Additionally, it is appropriate because they are linked to the app lifecycle, providing deregistration of those schemes once the app is uninstalled (unlike registerProtocolHandler()).
> 
> That's compelling, indeed - although the site could call `unregisterProtocolHandler()`. I guess this is interesting if protocols are "provisionally registered", but are inert until activated.
>
> As an aside, we probably want to be clear with what happens when `.unregisterProtocolHandler()` is called, if it's not already.
> 

So registering protocol handlers from the manifest file would register them for the installed Web app. Registering protocol handlers through `registerProtocolHandler()` would register the website through the browser, therefore calling `unregisterProtocolHandler()` would not unregister any handlers from installed Web apps. In a way, the two ways of registering handlers are different because they act on different scopes.

> > From the UX side, if an application needed to register to handle N protocols upon installing, it's bad UX to prompt the user N times for the permissions. With the protocols installed from the manifest, the user would only get a permission prompt the first time they link on a link.
> 
> And this would only be for that particular link type, right? Not a blanket approval for all registered things?
>

 Correct, it would be only for the particular link type that is triggered.  Security wise, every different protocol registration needs to be granted permission on first use of that particular link type.
 
> > Finally, we think it's about the constant evolution in HTML to make things more declarative. With the protocol_handlers member in the manifest, you don't need to rely on JS to register schemes for your installed app.
> 
> There are a lot of pros/cons here (personally, I like the imperative APIs over the declarative ones) - but let's keep this outside.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/972#issuecomment-874277141