- From: Ashley (Scirra) <notifications@github.com>
- Date: Tue, 17 Mar 2026 04:02:00 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/1209@github.com>
AshleyScirra created an issue (w3c/manifest#1209) I originally thought this was a bug and filed [this Chrome issue](https://issues.chromium.org/issues/491346042), but it sounds like it's by design - and I think this is the wrong design, so I'm filing a spec issue. If a PWA uses `scope_extensions`, no PWA can be installed from any of those scopes. This unreasonably limits the ability to install multiple PWAs. Consider this use case: - editor.example.com has a PWA to edit a document - docs.example.com has comprehensive documentation for the PWA Consider that the developer may want to make both installable PWAs (the editor as the main app, and docs as a way to peruse documentation while offline). Then suppose editor.example.com can open docs.example.com in a new window. This is still first-party content. However an annoying location bar appears at the top of docs.example.com because it's out of the original PWA scope. Suppose you then add an entry to `scope_extensions` to resolve that: now the first-party docs content can be shown inside the editor PWA without any location banner. However that then means if the user navigates to docs.example.com, the option to install the docs as a PWA is no longer available. It appears docs.example.com now falls under the scope of editor.example.com and so it is not possible to install separately any more. Worse, the browser UI offers to open the content on docs.example.com inside the editor.example.com PWA because it thinks they are one and the same. In our case which is another good example, we have three release channels: beta, stable and LTS. We want all to be on the same origin so they share authentication, settings, permissions etc. We have three PWA scopes: - https://editor.construct.net/beta/ - https://editor.construct.net/stable/ - https://editor.construct.net/lts/ Note the trailing slashes to ensure these have separate scopes. Each of those URLs is a redirect to the latest version in that channel, e.g. https://editor.construct.net/r475/, https://editor.construct.net/r476/, etc. As the stable channel is the default, it is also served on https://editor.construct.net/. Because the redirects are out of scope, then https://editor.construct.net must be added inside `scope_extensions` otherwise an annoying location banner always appears at the top of the window. However this then precludes installing different release channels side-by-side, as they all then fall under the same scope. This is something users really want and have asked us for. For example they may have a long-term project developed in the LTS release, but they want to occasionally open the beta release to experiment with new features. Here are two ideas to solve this: 1. Have separate notions of the primary scope and scope extensions. Installability should only be determined from the primary scope. 2. Separate the notion of "these origins are the very same PWA" and "these origins may be navigated to without appearing to be external". For example `scope_extensions` would count as origins for the very same PWA, and a new `allowed_navigations` field would determine which origins can be navigated to without showing the location banner. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/1209 You are receiving this because you are subscribed to this thread. Message ID: <w3c/manifest/issues/1209@github.com>
Received on Tuesday, 17 March 2026 11:02:07 UTC