Clarify intended use cases (in-scope vs out-of-scope)

[mgiuca]

The explainer currently outlines only one use case:

The user clicks on a Spotify link in their native e-mail application, (eg., https://open.spotify.com/album/7FA9xfqPrBaja1sEv15DU2 in the Outlook app), which launches their default browser. Because the user already has the Spotify PWA installed and registered as a URL handler with their default browser, the URL activation launches the PWA instead of a new tab.

Note that this use case would be an in-scope case: the URL is within scope of the launched PWA. This particular case is trivial. It doesn't require any of the mechanisms proposed in this explainer; a simple "enable link capturing for in-scope URLs" flag would suffice, as proposed here or here. OS-level registration would be a feature of the user agent, not the specification.

This use case doesn't justify all of the other features proposed here:

• A complex URL scope syntax with exclusions.
• Cross-origin link capturing.
• Disambiguation in cases where multiple PWAs handle the same URL.

This was raised on MicrosoftEdge/MSEdgeExplainers#300 and you indicated that cross-origin was needed for vanity URLs on another origin. That isn't mentioned as a use case here.

I think this proposal needs to focus exclusively on the out-of-scope use cases, since those are the only cases that require the features being proposed here. At least, it should clarify the distinction between in-scope and out-of-scope cases, because they have quite different requirements and implementation details.

(There may also be a case where you want to capture some but not all of the URLs in an app's scope. If that's important, please state it as another use case.)

[mgiuca]

There are at least two distinct use cases for cross-origin link capturing (do you intend to support both, or just one):

• "Vanity" URLs (e.g., conto.so) that immediately redirect to the "real" URL.
• Unrelated, but participating, properties, that will not redirect, but should be considered part of the PWA.

I'd like to carefully consider the needs of the different use cases. For example, as I said on MicrosoftEdge/MSEdgeExplainers#300, the vanity case might be solved by a simple redirect (though the experience will be poor right now, we can try to fix it). The "PWA that lives across multiple origins" does seem to be something people want to build, but I don't think we can fix it with a URL handler. We need a more holistic concept of a PWA whose scope spans across origins. (Otherwise, you'll always see a URL bar when using the out-of-scope origin within the PWA.)

So at the moment, I'm not convinced that this is the right solution to either use case. I think the first step towards coming to an understanding is clearly enumerating the use cases.

[LuHuangMSFT]

I agree that the explainer should be clearer about enumerating the use cases and justifying the proposed new features.

One general requirement that I want to add/highlight is the ability for link capture to open PWA windows without first opening a browser tab. This is especially important in the context of mobile devices, where we would like the PWA experience to be more similar to native apps. To that end, we want to come up with a declarative format that can be registered with OSes for OS level URL handling. This may require app wrappers, such as appx on Windows, webapk on Android, etc. When OS level URL handling is not available, as is the case now, the browser should provide the same service as unobtrusively as possible.

"Vanity" URLs that redirect to "real" URL - redirection is insufficient to provide the experience outlined above when handling out-of-browser link navigation.

• This does not matter for in-browser link navigation because the browser is already open and redirection is mostly invisible to the user.
• For out-of-browser link navigation, the browser window has to open, navigate to the vanity URL, then follow the redirect. If there is more than one https protocol handler registered with the OS, the user first has to provide input to choose one and may not even choose the browser with the installed PWA. This takes many more seconds and requires an additional user action.
• Without OS level URL handling registration, user action might still be necessary to select a https protocol handler. However, with browser level URL handling, there would be no need to make network access to the vanity domain, and no need to display the normal browser window.

[LuHuangMSFT]

The "PWA that lives across multiple origins" does seem to be something people want to build, but I don't think we can fix it with a URL handler. We need a more holistic concept of a PWA whose scope spans across origins. (Otherwise, you'll always see a URL bar when using the out-of-scope origin within the PWA.)

This is a different concept that I was imagining. "PWA that lives across multiple origins", implies to me that there is a one-to-one relationship between the resources on different domains and the PWA. I'm thinking more of "resources that can be used by different PWAs". The PWA that claims to be a URL handler for those resources does not claim ownership of those resources. (Adding URLs to a collective scope doesn't have to imply ownership either. I could write a PWA manifest that scopes to another domain I don't control, but I don't think that is allowed currently. Incidentally, this is something I have seen requested quite often - essentially the ability to write third party apps.)

• Eg. A data repository site can associate with a number of visualization apps. The actual data lives outside of the apps' scopes. Also, a redirect would not work because there is no single app to redirect to.
• A website could dynamically generate content on its own domain with accompanying static URLs, to be consumed by partnering PWAs when those URLs are shared and activated.
• We could maybe also draw an analogy to file handling here, where a PWA can claim to be a handler for a file type.

I don't think scope necessarily has to imply ownership but, given how manifests and scopes are always co-located, that seems to be the case currently. I also think there should be some distinction between the set of files/URLs that compose the app itself, and the URLs that can be its content/resources. If the latter is sub-classified under "scope". then I don't think the manifest structure makes much difference in that case. Additionally, I think it is beneficial to have a separate url_handlers clearly associated with URL handling behavior(either registration with the OS, or in the browser itself) rather than adding a flag to opt-in the entire scope for URL handling.

[wanderview]

For out-of-browser link navigation, the browser window has to open, navigate to the vanity URL, then follow the redirect.

Can you explain this further? If the server responses with a 302 status code I don't think the browser has to open a window for the original URL at all. Indeed, it probably needs to fully evaluate all redirects before opening a window because it must select a process locked to the appropriate final origin.

[LuHuangMSFT]

^ I think you're probably right. On desktop Chrome, is that done in the browser process before displaying any UI?

On some mobile platforms, the browser starts with a splash screen. It would be confusing to the user to see a browser splash screen immediately followed by an app splash screen, even if the redirects aren't displayed visually.

[wanderview]

In chromium it should be done in the browser process. Firefox at least used to do it in their child process, but the process is less important than when to show UX.

I can't speak to the splashscreens since that's more a browser product feature, but it seems they must handle redirects without flickering, etc.

[wanderview]

I think the more compelling case against relying on redirects is offline. How do you support offline access when someone types a vanity URL for your PWA? Relying on service workers for the vanity URL to provide the redirect is very expensive since it has to spin up an extra process, etc. See w3c/ServiceWorker#1457 for discussion about that.

[SamB]

I can't speak to the splashscreens since that's more a browser product feature, but it seems they must handle redirects without flickering, etc.

Actually, starting on Android 12, every app gets a splash screen if the Activity isn't still around; see: https://developer.android.com/develop/ui/views/launch/splash-screen

Basically, instead of just showing a blank window, the system shows the splash screen while the app is starting things up.

(The SplashScreen API basically just lets apps customize when and how the splash screen ends, which is beside the point.)

So, Android 12+ users will see a browser splash screen for any URL that has to bounce through the browser before getting to the right PWA (unless the relevant Activity is still in working order).