URL Protocol Handler Registration for web apps

[fabiorocha]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Protocol Handlers for web apps
• Specification or proposal URL: Explainer, Spec Issue
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1635272
• Mozillians who can provide input (optional): @annevk, @dbaron, @marcoscaceres

Other information

Chrome Intent to Prototype: https://groups.google.com/a/chromium.org/forum/?hl=en#!topic/blink-dev/x4Ev_l9Oj2U
WICG discussion: https://discourse.wicg.io/t/proposal-url-protocol-handler-registration-for-pwas/4276 (we have moved to discuss it in the spec issue).

[dbaron]

One of the key issues here, I think, is the relationship to registerProtocolHandler, and the risks of duplication or divergence. (How does this compare, say, to an approach where the manifest could indicate that an app will invoke registerProtocolHandler.)

I'd also note that some of the issues with registerProtocolHandler pointed out in both the explainer and the discourse thread would probably be better viewed as things that could be improved in registerProtocolHandler implementations rather than inherent deficiencies of it. (e.g., permission model could be different for PWAs, browsers could allow multiple registrations and make UX more understandable)

Also see w3ctag/design-reviews#482, and also cc @marcoscaceres .

[fabiorocha]

One of the key issues here, I think, is the relationship to registerProtocolHandler, and the risks of duplication or divergence. (How does this compare, say, to an approach where the manifest could indicate that an app will invoke registerProtocolHandler.)

The way I see it, we're proposing a different entry point for PWAs to register protocol handlers, and the only relationship it has to registerProtocolHandlers is that its parameters are proposed in a way that that API can be used under the hood. I personally think this is a better story than having that API behave differently depending on the context and having to handle all different possible interactions. This is similar to what Mozilla has done for WebExtensions. Granted, extensions are not standardized and I'm not sure if they rely on registerProtocolHandler internally, but I like its model of providing an entry point to its developer audience where and how it makes sense instead of relying on special behavior for the existing API. (Note: this might change with this proposal/work)

MSEdgeExplainers/#286 touches a bit on this. I'm curious to know how you see this working. Do you see any advantages on having the manifest serve as an indication instead of having just registerProtocolHandler called when the app is running? Can you point me to an example where this model worked? I'd love to dig in more.

I'd also note that some of the issues with registerProtocolHandler pointed out in both the explainer and the discourse thread would probably be better viewed as things that could be improved in registerProtocolHandler implementations rather than inherent deficiencies of it. (e.g., permission model could be different for PWAs, browsers could allow multiple registrations and make UX more understandable)

This is similar to feedback we received from nightpool in the WICG thread: "I would also hate to get into a situation where PWA apps have good protocol handler UX but non-PWA sites have avoidably bad UX because of a historical accident." -- and I am supportive of it and we can improve it along the way. However, even if we improved the UX of registerProtocolHandler I still believe manifest-based registration is the right UX for this feature for web apps. IMO, it makes sense for developers (other similar features are being added as manifest properties, e.g.: file handlers), it allows us to tie it to the app lifecyle, which is generally wanted for this type of feature, and it allows us to abstract a couple of things away UX-wise.

/cc @connor-moody @samtan-msft

[annevk]

It seems that WebExtensions could not use registerProtocolHandler() as per the explanation there registerProtocolHandler() is origin-bound. It might also make extension review harder than needed if it was a method call. Neither of those really apply here.

[diekus]

Hola, we've continued working on a way to add protocol handlers for installed Web apps and I'd like to bring attention back to this feature to ask for a request for position on the feature. Some time ago we satisfactorily cleared the TAG review which pointed at the concerns expressed in the earlier posts of this issue.

[marcoscaceres]

If anyone from Mozilla wants to review, the associated pull request is here:
w3c/manifest#972

I've left some questions there, which may be pertinent to any implementer.

[martinthomson]

Hi @fabiorocha and @diekus, Mozilla is currently not investing in PWAs. That's the reason for the delay and for why we're going to have to defer this request.

Our experts did have some comments when they took a brief look; they might offer some commentary.