[PWA URL Handling] General feedback

[jakearchibald]

This is just my personal feedback, I haven't coordinated with others.

URI vs URL

From https://url.spec.whatwg.org/#url-apis-elsewhere

If a standard decides to use a variant of the name "URL" for a feature it defines, it should name such a feature "url" (i.e., lowercase and with an "l" at the end). Names such as "URL", "URI", and "IRI" should not be used. However, if the name is a compound, "URL" (i.e., uppercase) is preferred, e.g., "newURL" and "oldURL".

Patterns vs code

The explainer proposes a new pattern matching format. I think this comes with a lot of risk. We don't want a situation where another spec needs a pattern, but the one here doesn't quite fit, so they create yet another format etc etc.

@wanderview is looking into a more general URL pattern matcher: https://github.com/wanderview/service-worker-scope-pattern-matching/blob/master/explainer.md.

However, does this need to be declarative? In service worker land, we generally prefer code to config, and only use config if we have a good reason why code won't work. Eg, something like a "launch" event could work here.

Cross origin

Can you go into more detail on why the cross-origin stuff is important? It seems pretty risky, and again we'd want to avoid a situation where we end up creating lots of things that do almost do the same thing.

[LuHuangMSFT]

Appreciate the feedback. Here are my thoughts below.

Cross origin

• It is a key scenario for our internal customers that a single PWA is able to handle links from outside its app scope, including those that are from a different domain. A simple example of why this is necessary is shortened links: "contoso.microsoft.com/some/resource/12345" and "contoso.ms/ghg4lkgjh" may refer to the same resource.
  • It may be possible in the future to identify groupings of such domains using ideas like https://github.com/krgovind/first-party-sets.
• There may be other reasons why the content (and the urls that represent them) is not within the scope of a compatible PWA. For example, there may be more than one compatible PWA that could present this content.
• It is possible to fulfill some of these requirements using clever redirects but it is likely that that introduces brittleness: a broken configuration could disable the feature for users.
• Native applications have the ability to register to handle urls from multiple domains. Have feature parity in PWAs could help developers make the switch to PWAs.
  • Android PWAs already have this ability thanks to the WebAPK distribution architecture.

Patterns vs Code

• I am a fan of the sw-launch design. I think it is a very good answer to the questions: "What should the launch behavior be when navigating to a url within a PWA?", and "What kind of navigations can be intercepted?"
• sw-launch's design does not account for letting the PWA handle urls outside of its scope.
• It is more natural for a PWA to express in patterns rather than code which urls outside of its scope it wishes to handle.
• A hybrid approach: It is possible to simplify the pattern matching format and have matches trigger sw-launch, thereby allowing finer url control to be done in code. This could help avoid running into issues where the format does not satisfy the developer's intent.
  • No matter what the pattern matching format is, I think it would still be a good idea to direct matches to sw-launch or a similar event system to be handled in code.

Format

• I share the same worry about introducing a new pattern-matching format that may not be able suit everyone's needs.
• I think an alternative idea could be "external scopes": scopes that can be, and agree to be, used by a PWA outside of where it is itself hosted. This would let us use a much simpler declarative format, albeit one that would not be as expressive in granularity.
• service-worker-scope-pattern-matching looks interesting but as written would only be useful for declaring a PWA's own scope, not external "scopes". However, if the pattern matching format is superior, I have no qualms about using it here to declare "external scopes" for a specific purpose (url handling in this case).

Questions

• When could sw-launch become available? What is its current status?

[wanderview]

It is a key scenario for our internal customers that a single PWA is able to handle links from outside its app scope, including those that are from a different domain. A simple example of why this is necessary is shortened links: "contoso.microsoft.com/some/resource/12345" and "contoso.ms/ghg4lkgjh" may refer to the same resource.

Note that the subject of vanity URLs also pertains to w3c/ServiceWorker#1457.

service-worker-scope-pattern-matching looks interesting but as written would only be useful for declaring a PWA's own scope, not external "scopes". However, if the pattern matching format is superior, I have no qualms about using it here to declare "external scopes" for a specific purpose (url handling in this case).

The intent is for the URLPattern part of the explainer to be consumable by other parts of the web platform. So if we had something called "external scopes" then it could be passed there. Anyway, its something I'm working on and the explainer is a bit out-of-date to my current thinking. Happy to sync on more details if you have questions/interest.

[LuHuangMSFT]

OS integration

I mentioned the requirement for cross-origin url matching as one reason why we need the format to be declarative in the web app manifest. There is another reason: once this effort gets underway, we would like to work on registering the url handling registrations with OSes. This would help PWAs behave more like native applications.

• OS platform features like Windows Apps for Websites, Apple App Site Association, Android App Link require declarative url handling registration formats.
• Using a declarative format for registering url handling allows for install-time validation and protects against some security issues.

[LuHuangMSFT]

@wanderview

I read the URLPattern explainer again much more closely. I especially appreciated the discussion about matching performance.

Correct me if I'm wrong, but I believe that explainer does not allow for sub-domain wildcard in the baseUrl. This would be a problem for us because we have a requirement that, for example, "organization1.contoso.com" and "organization2.contoso.com" can both be handled by the same PWA. That PWA would need to have to filter for "*.contoso.com" + paths.

It seems difficult to match a wildcard prefix with predictable performance if the base or baseUrl is allow to contain additional path segment beyond the origin/host. If the base is instead limited to being a origin/host, we could match it in reverse. Alternatively we could match the input url against a map of registered hosts by removing one sub-domain as a time.

[wanderview]

I think we can support wildcards in the host. If you used a pattern like that for service workers then the service worker API would reject. Basically we would compile the pattern to an internal representation with things like "has wildcard in host", etc and then the other APIs would check that.

The syntax is not finalized, but for hosts I was expecting to do something more like this:

new URLPattern({
  baseUrl: location.self,
  host: '*.example.com',
  path: '/foo/*',
});

The host and path parts would override the info in baseURL. So scheme, port, etc would come from baseURL in this case, but host and path override those parts. This example pattern would not be usable with service workers, but your API could possibly accept it.

[wanderview]

But in short, if you have requirements lets talk.

[LuHuangMSFT]

#316 changes all "URI" to "URL".
#318 calls out sw-launch as an option for the mechanism of launching a PWA when a match is found.

[mgiuca]

Hi, I have some additional feedback. As one of the authors of the WICG/sw-launch explainer, I think there's a lot of overlap here with sw-launch so I'm interested in either combining the two proposals, or teasing them apart so that they provide mutually exclusive functionality. I see you're already planning an update to the explainer that takes sw-launch into account.

Further feedback:

• "Launching PWAs due to in-browser link navigation. Instead, this explainer focuses on scenarios where the URI activation has occurred from outside of the browser." — I don't see why there needs to be a distinction here. You explicitly call out a use case of clicking a Spotify link from the native Outlook app, but what if I click a Spotify link from an email PWA? Why limit this to only activation from outside the browser?
• It's not clear to me how the browser is supposed to handle a URL from another scope. It says "If launched to handle a URI activation, browsers then launch a PWA" — but what does "launch a PWA" mean? Launching a PWA means opening a new application window, and navigating to a particular URL. What URL would you navigate to if opening an app from another scope?
  • For example, if you have an app at https://contoso.com, which is set up to capture links from https://conto.so, if the OS activates the URL https://conto.so/foo, the browser will launch the https://contoso.com app, but what URL does it navigate to?
    • Does it navigate to the https://conto.so/foo (resulting in a custom tab bar at the top of the window?) That's unlikely to be the intended user experience.
    • Does it navigate to the start URL, but add some parameters to the end of the URL to say "this launch came from https://conto.so/foo"?
    • Does it fire an event to the service worker to say that a launch came in from this other scope? (Sounds like a job for sw-launch.)
• I do feel like the out-of-scope URL thing is a bit unusual here. If you want a "vanity URL", can't you just redirect and then have the redirection cause a link capture? (For example, https://conto.so/foo could redirect to https://contoso.com/foo which would then open in a new app window.)
  • The reason why native apps need to be able to have a 2-way relationship between the app and the URL being captured is because the app itself doesn't live at a particular URL. For example, on Android, the YouTube app and https://youtube.com have a 2-way relationship so that navigation to https://youtube.com can open in the app. But if YouTube were to become a PWA, the PWA would live at that URL; there is no need for a 2-way relationship other than vanity URLs that redirect into the PWA.
• I feel like a lot of what's being proposed here is getting around the inflexibility of "scope". If we do link capturing (something which we've wanted to do for a really long time; see sw-launch), I think it should be tied directly into the app's scope. We shouldn't define a parallel concept of "link capturing scope" which is separate from the main "app scope". If scope is too inflexible (e.g., need to be able to exclude sub-paths), then we should work on expanding the scope syntax, which @wanderview is doing here. We shouldn't design a more flexible version of scope, but have it apply only to link capturing.
• If you tie the link capturing to the existing app scope, then this starts to look a lot more like sw-launch, only without the service worker event part. That may be a benefit: it's taken us years to not implement the sw-launch event because it's really hard, and arguably, we should have done something simpler in the manifest. But it's also much less flexible, because it only allows us to open a new app window when navigated to, rather than be able to post a message to an existing app window.
• The fact that the special path /.well-known/pwa-site-association is baked into the spec is a bit restrictive. (I know native app digital links schemes do this.)
  • It's fairly unusual for a web spec to visit a hard-coded path relative to the root of an origin. As far as I know, the only other place that happens on the whole web platform is /favicon.ico, for extremely old historical reasons, and that is considered a mistake.
  • The name pwa-site-association: We've never (to my knowledge) formally used the term "PWA" in a spec; it has been thought of as a marketing term. I doubt we should call it this.

[wanderview]

Just a data point on one item here:

I do feel like the out-of-scope URL thing is a bit unusual here. If you want a "vanity URL", can't you just redirect and then have the redirection cause a link capture? (For example, https://conto.so/foo could redirect to https://contoso.com/foo which would then open in a new app window.)

This kind of redirect is quite heavyweight if the PWA wants to support offline for the vanity URL. You need a service worker installed on both origins. In browsers that do site isolation you then end up creating a process just to run the vanity URL SW that redirects to the real origin. Finally you create a second process to run the real origin SW and page. See w3c/ServiceWorker#1457 for more discussion.

[wanderview]

The fact that the special path /.well-known/pwa-site-association is baked into the spec is a bit restrictive. (I know native app digital links schemes do this.)

I have also wondered if this proposal should lean on origin policy instead of creating another well-known URL location.

But it also makes me kind of worried about the issues that have arisen for origin policy. Mainly, trying to support the following simultaneously:

1. Versioned updates of policy.
2. Aging out old policies.
3. Supporting offline use cases.
4. Maintain privacy, performance, etc.

Origin policy has run into difficulties here, though, because it wants to consult policies for cross-origin subresource loads. Maybe its not as difficult for only navigations like this use case is targeted at.

I think there is some discussion of updating in the explainer, but it would be nice if it explicitly covered how offline use cases would be satisfied.

[LuHuangMSFT]

Closing here. I will split up this thread into individual issues at https://github.com/WICG/pwa-url-handler/issues.