Scope extensions: Allow multiple same-origin scopes as well

[benfrancis]

Moved from WICG/pwa-url-handler#29 (comment) since it's probably more relevant here.

@LuHuangMSFT Thank you for pinging me regarding this proposal.

I'd suggest that any extension of the scope member should include allowing navigation scope to include multiple paths inside the same origin in addition to extending it to another origin.

In an ideal world I'd like to extend the scope member to support an object instead of a string, which describes a more complex navigation scope for an app.

That could include the ability to:

1. Define paths which should be included and excluded from the navigation scope
2. Define paths from other origins
3. Define a set of paths which should "stay in app" if navigated to from within the app, but should not be captured (e.g. for authentication)

{
  "start_url": "https://myapp.com/index.html",
  "scope": {
    "include": ["/", "https://myapp.io/"],
    "exclude": ["/about", "/contact"]
  },
  "stay_in_app": ["https://accounts.acme.com"]
}

For cross-origin scope, this would probably require some kind of origin association resource hosted at the other origin as you have suggested.

Unfortunately re-using the existing scope member may cause backwards compatibility issues. Another (more verbose) way of describing this could be a list of scope objects in a scopes member which define:

1. type - "include" or "exclude"
2. href - absolute, relative or cross-origin
3. capture - whether the app should capture navigations within this scope

"scopes": [
  {
    "type": "include",
    "href": "/",
  },
  {
    "type": "include",
    "href": "https://myapp.io/",
  },
  {
    "type": "exclude",
    "href": "/about",
  },
  {
    "type": "exclude",
    "href": "/contact",
  },
  {
    "type": "include",
    "href": "https://accounts.acme.com",
    "capture": false
  }
]

[alancutter]

capture - whether the app should capture navigations within this scope

This overlaps heavily with the handle_links proposal.

[benfrancis]

This overlaps heavily with the handle_links proposal.

Yes, that's correct. I don't think there's a need for a separate handle_links member because my understanding of section 6.2 of the current Web App Manifest specification (Deep Links) is that capturing navigations to URLs within the navigation scope of the application should already be the default behaviour. It's just that no user agent has implemented that yet (FWIW I think we did implement that in Firefox OS 2.6, but that was a long time ago now). For me, deep linking was always a fundamental feature of installable web apps and one of their biggest strengths compared with native apps (at the time).

In the first example I gave the idea of the stay_in_app member is to define a navigation scope which is not necessarily part of the app (and therefore should not capture links), but may stay inside the app if navigated to from inside the app, the classic use case being for authentication at another origin.

In the second example I gave, my thinking with the capture member of a scope object is that capture defaults to true, and this member is used to opt out of that behaviour. Sorry if that wasn't clear.

The second example is meant to show how the scope_extensions and handle_links proposals could all be part of an extended scope member instead, since deep linking is already meant to be a feature of navigation scope and there's a need for multiple same-origin scopes as well as cross-origin scopes. Unfortunately for backwards compatibility reasons that may now have to be called something else, like scopes.