Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URL Protocol Handler Registration for PWAs #482

Closed
1 task done
samtan-msft opened this issue Mar 6, 2020 · 23 comments
Closed
1 task done

URL Protocol Handler Registration for PWAs #482

samtan-msft opened this issue Mar 6, 2020 · 23 comments
Assignees
Labels
Resolution: satisfied The TAG is satisfied with this design Review type: CG early review An early review of general direction from a Community Group Venue: WICG

Comments

@samtan-msft
Copy link

samtan-msft commented Mar 6, 2020

Hello TAG!

I'm requesting a TAG review of URL Protocol Handler Registration for PWAs

This feature will allow web developers to register web applications as URL protocol handlers via a property in the web app manifest. The apps would open directly when a custom-scheme URL is visited. Implementation-wise, we intend to build this feature by reusing registerProtocolHandler internally and modifying the protocol handler registry and shell integration classes to account for the existence of PWAs. The idea is to avoid code duplication and maintain the APIs aligned. (see explainer and design doc for more details)

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • Existing major pieces of multi-stakeholder review or discussion of this design:
    w3c/manifest#846
    blink-dev
    WICG discourse thread
  • Major unresolved issues with or opposition to this design: None
  • This work is being funded by: Microsoft

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @fabiorocha @Maggers @connor-moody @samtan-msft

@samtan-msft samtan-msft added Progress: untriaged Review type: CG early review An early review of general direction from a Community Group labels Mar 6, 2020
@kenchris kenchris self-assigned this Mar 11, 2020
@torgo
Copy link
Member

torgo commented Mar 11, 2020

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

@torgo torgo self-assigned this Mar 11, 2020
@torgo torgo added this to the 2020-03-16-week milestone Mar 11, 2020
@dbaron dbaron self-assigned this Mar 11, 2020
@hober hober self-assigned this Mar 16, 2020
@fabiorocha
Copy link

fabiorocha commented Mar 18, 2020

@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?

@kenchris kenchris mentioned this issue Mar 24, 2020
1 task
@samtan-msft
Copy link
Author

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

@marcoscaceres
Copy link
Contributor

@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 :)

@torgo
Copy link
Member

torgo commented May 11, 2020

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."

@hober
Copy link
Contributor

hober commented May 26, 2020

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 mozilla/standards-positions#340 (comment). 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.

@plinss plinss added the Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review label Jun 7, 2020
@plinss plinss removed this from the 2020-05-21-f2f milestone Jun 7, 2020
@plinss plinss added this to the 2020-09-07-f2f milestone Aug 24, 2020
@hober
Copy link
Contributor

hober commented Sep 22, 2020

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

Any thoughts on the above?

@fabiorocha
Copy link

fabiorocha commented Sep 23, 2020

@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
Copy link
Contributor

hober commented Oct 12, 2020

@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.

@plinss plinss removed this from the 2020-10-12-week milestone Oct 19, 2020
@torgo
Copy link
Member

torgo commented Jan 26, 2021

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?

@diekus
Copy link

diekus commented Mar 8, 2021

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

@domenic
Copy link
Member

domenic commented Mar 8, 2021

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 .

@aarongustafson
Copy link

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)?

@domenic
Copy link
Member

domenic commented Mar 9, 2021

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.

@aarongustafson
Copy link

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

@domenic
Copy link
Member

domenic commented Mar 9, 2021

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.

@marcoscaceres
Copy link
Contributor

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.

@kenchris
Copy link

kenchris commented May 12, 2021

@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/

@diekus
Copy link

diekus commented May 12, 2021

@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.

@kenchris
Copy link

@diekus I added you now

@atanassov
Copy link

@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?

@diekus
Copy link

diekus commented May 12, 2021

@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?

@kenchris
Copy link

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!

@atanassov atanassov added Resolution: satisfied The TAG is satisfied with this design and removed Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Progress: stalled labels May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: satisfied The TAG is satisfied with this design Review type: CG early review An early review of general direction from a Community Group Venue: WICG
Projects
None yet
Development

No branches or pull requests