whatwg
Consider removing unregisterProtocolHandler()
As registerProtocolHandler() is essentially a user permission, it's not clear to me that it makes sense to let the site manage these after the fact. It also doesn't seem likely that a site would (be able to) cleanup as it takes the service down. So I'm a bit hesitant to endorse adding this to Firefox.
I am curious to hear what other people think.
cc @ericlaw1979 @fred-wang
I'm also curious about that too. I filled https://bugzilla.mozilla.org/show_bug.cgi?id=1631477 because it was appearing in WPT test html/webappapis/system-state-and-capabilities/the-navigator-object/protocol.https.html and apparently Chrome implements it, but I don't know what were the rationale and use cases...
The only scenario where I think unregisterProtocolHandler might sorta make sense is if a bigger PWA/app itself over time and drops support for some contended protocol (e.g. "calendar"); freeing up that protocol in some future version of the app might be nice to ensure that the user gets an OS picker the next time they try to use one of those links.
Yeah, there's an opportunity for some good, but I think the user agent mostly has to design its UI around that not happening at which point it's unclear that having it places the right incentives on user agents.
It might also be surprising to the user as other things they configure this way cannot be silently revoked, though I suppose there's nothing preventing the user agent from letting the user confirm the unregistering.
This was added in https://github.com/whatwg/html/commit/931c9ad82edc3c504d1a1d149174257772a31d80
Rationale: https://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-August/075259.html
- Introduce an unregisterProtocolHandler() function.
Such a function is desirable because it allows sites to remove outdated handlers from clients and would enable clients to provide a UI for managing their registered protocol handlers.
Agreed.
(isProtocolHandlerRegistered was removed in https://github.com/whatwg/html/pull/3027)
