Closed yoavweiss closed 1 year ago
The precise mapping between web app and window client is unstable within Chromium's implementation. I think I'll just explicitly say in the spec that the mapping is up to the user agent but is probably at least window clients that were created via https://wicg.github.io/sw-launch/#dfn-prepare-a-new-web-app-launch-client.
The precise mapping between web app and window client is unstable within Chromium's implementation.
What do you mean?
I think it'd be good to at least include a handwavy description of what that mapping is:
Discussed with @mgiuca, decided upon letting the user agent pick from top-level browser contexts that have the manifest applied or are in scope of the web app.
Reading the spec, I think we need to be a bit more precise about the association. I think just using the language of the manifest spec is fine: a TLBC "having a manifest applied to it".
For example:
(I think those two examples are all you need to update.)
The launch_handler spec defines https://wicg.github.io/web-app-launch/#dfn-web-app-launch-client however this is redundant with the existing https://www.w3.org/TR/appmanifest/#dfn-application-context definition. I should make use of this existing definition and drop the "client" one. This will remove the "associated with" ambiguity.
I had originally wanted to keep the exact association between web apps and top-level browsing contexts up to the user agent should the UA wish to link capture web app launches into browser tabs however I think it can be up to the UA for browser tabs to have the in scope web app manifest applied to them if they want to or not.
Resolved by removing the concept of "web app launch client" in favour of reusing "application context".
In a few places we check if a web app has an associated window client, but it's not 100% clear from reading the spec what that means. Defining e.g. a map the user agent maintains would help make that concept clearer.