Open benfrancis opened 3 years ago
capture
- whether the app should capture navigations within this scope
This overlaps heavily with the handle_links
proposal.
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
.
Moved from https://github.com/WICG/pwa-url-handler/issues/29#issuecomment-921747243 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:
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:type
- "include" or "exclude"href
- absolute, relative or cross-origincapture
- whether the app should capture navigations within this scope