Describe how an out-of-scope URL should be launched

[mgiuca]

If launched to handle a URL activation, browsers then launch a PWA with matching url_handlers to handle that URL.

This is lacking detail about what it means to "launch a PWA". In particular, what URL would the launched PWA open to?

Ah, I see this is covered below in "Browser Changes":

If there is a match, launch the PWA and load the URL in the PWA window instead of the browser window.

When capturing URLs that are within the scope of the app, this makes sense: navigate to that URL within the application context.

When capturing URLs that are outside of the scope of the app (either in a path out of scope, or on a different origin), is that really what you want? This will mean that the app window opens right into an out-of-scope URL bar. That is probably a poor user experience. We need use cases to consider how to treat this (see #7: I'd like to see explicit out-of-scope use cases since that's where all of the complexity lies).

Would the site be expected to redirect to an in-scope URL right away (as we can probably expect from a "vanity domain")? That might solve the problem, but you could see a flash of the URL bar.

Another approach could be to treat this like protocol handlers (or a share target, or a file handler) and not navigate to the out-of-scope URL at all, rather pass the out-of-scope URL as a parameter to the URL handler.

For example, add a url_handler_action member, which contains a URL template to be filled in:

"url_handler_action": "/external?url=%s"

Now if the user navigates to https://www.conto.so/foo/bar, the browser will intercept this, find the URL handling PWA at www.contoso.com, and launch a new PWA window navigated to the url: https://contoso.com/external?url=https%3A%2F%2Fwww.conto.so%2Ffoo%2Fbar. Now the PWA can do whatever it wants with this information, for example parse the URL, figure out the foo/bar path, and redirect to the appropriate internal page.

The above would only apply to out-of-scope URLs. It's why I think you should focus this proposal on out-of-scope URLs only, because that's where all the complexity lies.

[LuHuangMSFT]

I think having event handlers would be the ideal solution. Short of having that, or as a default if that is implemented but there is no event handler provided, the pass-as-parameter solution works well.

[LuHuangMSFT]

We can focus on out-of-scope URLs in this explainer. I think it would still be useful if the format for including/excluding URLs can be used on in-scope URLs for URL handling, but perhaps there is a strong argument that all or none of in-scope URLs should used for URL handling en bloc.

[mhochk]

Adding an optional url_handler_action member sounds like a nice addition, but I wouldn't want to make it required just because a URL is out-of-scope.

Sites that are using vanity domains could "just work" the same as they do in browsers today (i.e. redirects) if the base experience is still navigating to the URL, regardless of scope. If they wanted to improve their user experience they could certainly add a url_handler_action entry and any site-side support needed.