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. 

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

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