Consider extending the scope member instead

[benfrancis]

As I understand it, the kind of deep linking this proposal describes has always been an intended use case of the navigation scope of a web app manifest, but is not yet supported by user agents.

There was extensive discussion around this topic in #144 and elsewhere for a number of years, including studies into the URL scopes of hundreds of existing popular web sites and web applications [1].

I would suggest that for the use case of link capture from outside the app, the scope member of the manifest should be used, and extended to include multiple scope URLs if necessary.

For example, by turning scope into an array rather than a string as I proposed in 2014, and having an installed web application capture navigations to URLs which fall within those scopes.

{
  "start_url": "https://foo.com/bar",
  "scope": ["/bar", "/baz", "https://qux.com"]
}

1. There are also other use cases to take into account there, such as URLs which should not necessarily be captured by an external navigation, but should stay within the application context if navigated to from there (the most common case being authentication via another origin, e.g. mail.google.com authenticating at accounts.google.com).

[wanderview]

Just FYI, I am already planning to work on arrays of scopes in my pattern scopes effort:

https://github.com/WICG/urlpattern/blob/master/explainer.md

Lists of scopes were added to this effort after feedback at TPAC 2019. I'm working on the service worker scopes first, but then plan to bring the same features to manifest scopes to maintain parity.

I think all this is compatible with what you are suggesting here, but I wanted to call it out in case work starts in earnest here. I'd like to stay in the loop and aligned with your plans. Thanks!

[mandymsft]

FYI, there are a few new standards proposals that aim to provide better-defined end-to-end URL handling. One of them is scope_extensions, which will allow PWAs to include links from other origins as part of the scope. The link handling behavior will be defined by handle_links, and app launch by launch_handlers.

[benfrancis]

Thanks for the pointers @mandymsft.

I can't help but feel that the use cases of all three of these proposed new members could be achieved through an extension of the existing scope and display members, backwards compatibility issues not-withstanding.

For example, by turning scope into an array rather than a string as I proposed in 2014, and having an installed web application capture navigations to URLs which fall within those scopes

I've added an updated proposal regarding multiple scopes here WICG/manifest-incubations#40