Relationship with Mozilla's protocol_handlers

[fred-wang]

@fabiorocha @joselea @ericlaw1979 @connor-moody

Hi, thanks for working on this proposal!

I don't know if you are aware, but Firefox implements a similar protocol_handlers for their WebExtensions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers

This is very similar to this proposal, except that the names in this proposal to match the argument of registerProtocolHandler() while Mozilla implemented different ones:

"scheme" <-> "protocol"
"url" <-> "uriTemplate"
"title" (optional) <-> "name" (mandatory)
"icon" (optional) <-> no equivalent

I couldn't find any reference to Mozilla's implementation in this proposal. I guess it should at least be mentioned in https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md#related-apis

Per #278 I understand the title and icon field are going to be removed. I guess Mozilla agrees that the corresponding protocol_handlers.name from should be removed from their implementation as per @ annevk 's comment on whatwg/html#5425

I believe it would be good to have the two interoperable proposals, but not sure what is Mozilla / Microsoft's preference here.

[fabiorocha]

Hey @fred-wang, thanks for the issue.

We were aware of Mozilla's implementation but since that was for WebExtensions we thought it was mostly orthogonal to what we're proposing. We can certainly mention it in our explainer to call that out.

I believe it would be good to have the two interoperable proposals, but not sure what is Mozilla / Microsoft's preference here.

Can you elaborate on this?

[fred-wang]

Hey @fred-wang, thanks for the issue.

We were are of Mozilla's implementation but since that was for WebExtensions we thought it was mostly orthogonal to what we're proposing. We can certainly mention it in our explainer to call that out.

Hi,

I'm not sure how PWA are implemented in Edge but I was assuming you'd relied on the same code base as browser extension and so your proposal would work for https://docs.microsoft.com/en-us/microsoft-edge/extensions-chromium too. In any case, I'm interested in implementing something like that for Chromium extensions too FWIW, so it would be supported by Edge.

I believe it would be good to have the two interoperable proposals, but not sure what is Mozilla / Microsoft's preference here.

Can you elaborate on this?

It seems the JSON manifest have very similar structure but to make web extensions compatible, one would need to use the same keyword names. Now that you are saying Edge extension are orthogonal to PWA maybe it's not a big deal, but still I believe it would be nice for wer developers to have consistent keyword names. So the possible options I see are either new proposals should follow Mozilla's existing keyword names or otherwise Mozilla should change the keyword names (maybe keeping old ones for backward compatibility) to match the new proposals.

[fabiorocha]

Thanks for the clarification.

I'm not sure how PWA are implemented in Edge but I was assuming you'd relied on the same code base as browser extension and so your proposal would work for https://docs.microsoft.com/en-us/microsoft-edge/extensions-chromium too. In any case, I'm interested in implementing something like that for Chromium extensions too FWIW, so it would be supported by Edge.

Yes, internally PWAs are implemented on top of extensions (for now -- this is being reworked as we speak). What I meant is that we have no intention of adding URL Protocol Handler support for extensions as part of this work, but I'm curious that you said you are interested in implementing it. Do you have an explainer I can have a look or something in that regard?

It seems the JSON manifest have very similar structure but to make web extensions compatible, one would need to use the same keyword names. Now that you are saying Edge extension are orthogonal to PWA maybe it's not a big deal, but still I believe it would be nice for wer developers to have consistent keyword names. So the possible options I see are either new proposals should follow Mozilla's existing keyword names or otherwise Mozilla should change the keyword names (maybe keeping old ones for backward compatibility) to match the new proposals.

Yes, in principle I agree -- if support is added for both PWAs and extensions, ideally the JSON manifest properties would look as similar as possible. We also have to account for the existing registerProtocolHandler API, and ideally we would align with that since it's part of a standard already. Maybe all implementations should move towards protocol and url (keeping backwards compatibility where it makes sense)?

[fred-wang]

Yes, internally PWAs are implemented on top of extensions (for now -- this is being reworked as we speak). What I meant is that we have no intention of adding URL Protocol Handler support for extensions as part of this work, but I'm curious that you said you are interested in implementing it. Do you have an explainer I can have a look or something in that regard?

Not yet, this will be part of https://github.com/ipfs/devgrants/blob/master/targeted-grants/protocol-handler-api-for-browser-extensions.md which will hopefully start soon. Maybe we can follow-up on this later, see if we can collaborate and avoid duplicate effort?

Yes, in principle I agree -- if support is added for both PWAs and extensions, ideally the JSON manifest properties would look as similar as possible. We also have to account for the existing registerProtocolHandler API, and ideally we would align with that since it's part of a standard already. Maybe all implementations should move towards protocol and url (keeping backwards compatibility where it makes sense)?

I think this is a sensible proposal (and I would be happy to send patches to Firefox to do that). As I said, we also have to take into account backward compatibility, so I suspect Mozilla reviewers will be willing to continue to support legacy key names anyway, even if they implement the new ones.

[connor-moody]

I agree that it makes sense to use protocol and url to align as closely as possible to registerProtocolHandler. I will update our proposal accordingly.

[fabiorocha]

Not yet, this will be part of https://github.com/ipfs/devgrants/blob/master/targeted-grants/protocol-handler-api-for-browser-extensions.md which will hopefully start soon. Maybe we can follow-up on this later, see if we can collaborate and avoid duplicate effort?

Absolutely -- we should be able to reuse a substantial part of the code we'll be adding to support this on extensions as well. I can keep you in the loop once we start submitting CLs against Chromium.

I think this is a sensible proposal (and I would be happy to send patches to Firefox to do that). As I said, we also have to take into account backward compatibility, so I suspect Mozilla reviewers will be willing to continue to support legacy key names anyway, even if they implement the new ones.

Thanks. @samtan-msft or I will submit a PR against our explainer to mention the existing support on Firefox's WebExtensions and the desire to add support for this to extensions across all browsers.

[fred-wang]

I agree that it makes sense to use protocol and url to align as closely as possible to registerProtocolHandler. I will update our proposal accordingly.

@connor-moody The spec uses scheme though so I think your previous proposal was correct:
https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

(MDN calls the argument "protocol")