@nightpool, thank you for your insightful comments.
To address your feedback given from the perspective of a web developer:
We have also seen issues with registerProtocolHandler including:
- Only allowing one registration per handler
- Calling unregisterProtocolHandler deregisters the protocol only with the browser, not the OS
- Prompting the user to accept/deny something that they aren’t particularly knowledgeable about
This behavior isn’t part of the spec (https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers), so it could be changed. However, it would be outside the scope of this proposal to suggest UX fixes for the registerProtocolHandler API.
I agree that there is no link fallback story if a user is accessing the link from a browser. However, protocols are an OS level concept with an OS level fallback story. I think the best we can do is allow the OS to fallback when accessing protocols from native apps and pitch PWA protocol handling for what it is - a web hook into OS functionality.
To address your feedback from the perspective of a spec writer:
I agree with the divisions you’ve made among protocol types, however, your characterization of group 1 seems to downplay the importance of backwards compatibility with app-specific protocols. From a web-only perspective, I agree that app-specific links are less relevant and introduce compatibility issues. However, this proposal aims to support existing ecosystems of native applications, where protocols from group 1 are just as relevant as those in group 2 and 3.
I’ll also add that any native application can register to use any protocol, so a “proprietary” protocol introduced by a native app ecosystem can be handled by an arbitrary third-party application. One example is the Microsoft Office URI protocol (https://docs.microsoft.com/en-us/office/client-developer/office-uri-schemes) that is publicly documented, allowing other productivity software to handle a protocol that initially appears to app-specific. I use this example to point out that the lines between groups 1, 2, and 3 are blurred when you consider protocols as an OS feature meant to provide integration between native applications.