Navigator.registerProtocolHandler is defined here:
https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

• It accepts two arguments "scheme" and "url".
• "title" is being removed (bug 1631464)

Microsoft is working on a proposal for PWA which will be using the same arguments (it seems they mistakenly renamed "scheme" to "protocol" though):
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md#url-protocol-handler-registration-for-pwas

Igalia is interested in implemented protocol_handlers in Chromium's extension, we will likely follow the HTML spec and Microsoft's PWA proposal.

Current Mozilla's WebExtensions is as follows:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers

• "protocol" is mandatory, equivalent to registerProtocolHandler's "scheme"
• "uriTemplate" is mandatory, equivalent to registerProtocolHandler's "uri"
• "name" is mandatory, equivalent to the removed registerProtocolHandler's "title"

This bug is to propose to provide new keys "scheme" and "uri" that can be used instead of "protocol" and "uriTemplate". "name" would become optional, the prompt can use a string with the overridden scheme in place of a developer-specified string. This would improve compatibility with Chromium and make things more consistent with HTML.

Shouldn't the key be "url" for improved compatibility? (And for consistency with the web platform.)

(In reply to Anne (:annevk) from comment #2)

Shouldn't the key be "url" for improved compatibility? (And for consistency with the web platform.)

Right, it should be url, not uri.

Ideally, we should also unify the two sets of whitelisted protocols.

Just for the record, the current plan is likely to be:

• Keep "protocol"
• Add "url" as an alias for "uriTemplate" and deprecate the latter.
• Make "name" optional

Moving off our triage list, to P5 since this is a contributor patch that will come later when its ready.

Not working on this anymore.