@samtan-msft thanks for sending this. Do you have an idea where this might go after incubation in WICG?

@torgo we initially thought about having it incubated in WICG, but as discussed on this thread the spec side of this work might be rather small and it has been suggested it could be treated as a spec bug and discussed as an issue on the manifest repo. What do you think?

@marcoscaceres how does that sound to you? We already have w3c/manifest#846, and we could just iterate there?

Hey, quick question, is anyone looking at this on the TAG side at this moment?

@marcoscaceres how does that sound to you? We already have w3c/manifest#846, and we could just iterate there?

Sorry I missed this earlier. That seems fine... however, it doesn't hurt to get TAG feedback :)

We are re-evaluating based on the new info in w3c/manifest#846... @marcoscaceres do you have any additional thoughts on this you could share in the context of this review? One thing we're concerned about is the possibility for things to get "out of sync."

Hi @fabiorocha @Maggers @connor-moody @samtan-msft!

@kenchris and I looked at this during a breakout of this week's TAG F2F. Overall we like the idea of adding this functionality to Web App Manifest, but we share the concerns our colleague @dbaron raised in https://github.com/mozilla/standards-positions/issues/340#issuecomment-631797523. We'd like to see this new manifest feature and the existing registerProtocolHandler() specced on top of a common underlying model, like how the Fetch spec unified the model for loading subresources. That way we could all trust that these things wouldn't get out-of-sync, and that they could have consistent UIs, permissions, etc. So ideally you'd have a pair of pull requests, one on Web App Manifest and one on HTML, that refactored the existing HTML text to provide the underlying model, and then exposed an additional API into that model in Web App Manifest.

Hi @fabiorocha @Maggers @connor-moody @samtan-msft,

Any thoughts on the above?

@hober My sincere apologies for letting this fall through the cracks. Thanks for the ping!

I think that makes a lot of sense, conceptually. Would you have pointers to the Fetch changes you mentioned as an example for this? Do you think both changes need to be staged at the same time or can one come before the other? I'd appreciate further guidance here.

@hober My sincere apologies for letting this fall through the cracks. Thanks for the ping!

I think that makes a lot of sense, conceptually. Would you have pointers to the Fetch changes you mentioned as an example for this?

The addition of the Fetch spec itself is the change I was referring to. Before Fetch, we had XHR. When Fetch got specced, a common model was defined that both XHR and the Fetch API could be defined on top of.

Do you think both changes need to be staged at the same time or can one come before the other?

I think it would be best if they were both staged at the same time; that way, each can link to the other so people understand why the changes are happening. If one came before the other, it should probably be the HTML change that happens first.

Hi @fabiorocha - @kenchris and I are just coming back to this issue in our "f2f" today and we're wondering if there has been any update? Can you let us know the current status? Is this something we should close for now?

Hola TAG,

We are looking into this. We opted for not changing the HTML5 spec and are rather thinking of making the Manifest spec dependent on the HTML one by referencing parts of it. We are working on the PR and will update with more info on this very soon.

gracias

Hey, HTML spec editor here. I don't think it's appropriate to change how navigation works without changing the HTML spec... See also https://github.com/w3ctag/design-principles/issues/184 and https://annevankesteren.nl/2014/02/monkey-patch .

Hey, HTML spec editor here. I don't think it's appropriate to change how navigation works without changing the HTML spec... See also w3ctag/design-principles#184 and https://annevankesteren.nl/2014/02/monkey-patch.

@domenic I don’t believe we are monkey patching. Our current plan—which @diekus is referring to—is to reference the HTML spec’s logic for normalizing/vetting protocol handlers, which is analogous to how ImageResource references HTML’s sizes parsing and how the Manifest currently references ImageResource processing and the Screen Orientation API. The reason for the reference (as opposed to defining a bespoke mechanism) is that any protocols that get added to (or removed from) HTML spec will get picked up automatically.

Assuming HTML doesn’t abandon the Protocol Handler API, we don’t foresee it becoming an issue. And if it comes to pass that registerProtocolHandler() becomes deprecated or is otherwise removed from the spec, we’ll resolve the ReSpec issue by bringing the referenced normalization logic into the Manifest spec.

As I understand it, the plumbing of the two approaches will be largely the same as this is, essentially, a declarative means of doing what registerProtocolHandler currently does programmatically (@fabiorocha and @diekus can get into the specifics on that, if needed); the only difference will be routing users to the installed PWA as opposed to the browser itself. As it is an installed PWA-specific behavior, it feels like that that should be defined in the Manifest spec, as opposed to HTML. Or are you thinking that we should include the navigation resolution (PWA vs. browser) in HTML so that calls to registerProtocolHandler, if made from within the context of an installed PWA, could use it as well (and we would just reference that from the Manifest)?

Hmm, maybe I misunderstood this then. Sure, definitely reference HTML's logic for normalizing/vetting protocol handlers.

But what spec will be modified to actually say that when a manifest registers for web+music://, navigations to web+music:// must launch the PWA? My point is that specifying that requires changes to HTML. If this were instead specified in the manifest spec, then that would be a monkeypatch of the problematic kind discussed above.

Or are you thinking that we should include the navigation resolution (PWA vs. browser) in HTML so that calls to registerProtocolHandler, if made from within the context of an installed PWA, could use it as well (and we would just reference that from the Manifest)?

Indeed, navigation is defined in HTML. However this is orthogonal to registerProtocolHandler. Any navigations that are intercepted, regardless of whether they're intercepted because of registerProtocolHandler or because of some manifest entry, are handled by HTML.

@domenic Thinking about verbiage, how would you frame the state of being installed? Is that considered/mentioned elsewhere in the HTML spec?

So far I am not aware of any web platform features which work differently in installed contexts vs. not. (That might be a good architectural issue for the TAG to consider for this review!)

If you did want to proceed down that path, introducing such a definition (either in the manifest spec or the HTML spec) which HTML could reference would make sense.

So far I am not aware of any web platform features which work differently in installed contexts vs. not. (That might be a good architectural issue for the TAG to consider for this review!)

Let's hope we don't start getting that kind of divergence. That would not be great.

If you did want to proceed down that path, introducing such a definition (either in the manifest spec or the HTML spec) which HTML could reference would make sense.

Agree. Though I'm hopeful that apart from very subtle/transparent things (e.g., maybe an increased storage quota, or slightly longer cookie persistence), nothing will differentiate installed from regular web apps.

@diekus maybe you want to add your self to primary contacts and give us an update on the status of this

Btw this was published yesterday: https://web.dev/url-protocol-handler/

@kenchris Hola Kenny ! How do I add myself as "primary contact"? I am the PM for this feature so indeed I am your preferred point of contact. (Sorry my first time helping with a TAG review).

Thanks for the heads up about the web.dev article, our team at MS collaborated with this indeed!

To give you an update about this, we have submitted 2 changes to the HTML spec to add 2 new definitions to it to align the manifest spec with the processes in the registration and invocation of protocol handlers in the HTML one. You can see the PRs here and here. They have both been merged and I have unblocked this to continue work on the manifest spec.

@diekus I added you now

@diekus thank you for the quick reply and detailed update. Looking how far this has matured it looks like we should be able to sign off unless there is anything else in your mind that we need to go over?

@atanassov All is good on our side and I'm happy to sign off. Just out of curiosity, in the TAG review process, what does this sign off mean? is it like an A+ on your grades?

We (@torgo, me and @atanassov) looked at this in our breakout today and we are happy with the progress and the collaboration with WHATWG on getting this aligned with existing specs and getting the changes incorporated into HTML.

Going to close this! Thanks for bringing this to the TAG!