scope_extensions unreasonably prevents installation of multiple PWAs

[AshleyScirra]

I originally thought this was a bug and filed this Chrome issue, 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 other 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.

[mkruisselbrink]

In Chrome the primary reason we don't show the installation prompt when you're "in scope" for an already installed app is because we don't want to show both a "open in app" and "install app" prompt at the same time. So with that in mind, would another possible solution be having a way to declare which URLs should actually be "captured" by the app? I.e. to distinguish "this URL is in scope/should not show a out-of-scope banner" from "navigations to this URL should be considered navigations to this app and launch the app or give the option to launch the app". We've had other requests for something like that as well, and it seems like that is essentially your problem/request as well.

[AshleyScirra]

My view is that it is not appropriate to show "open in app" for origins in scope_extensions - the way I look at it, the primary scope is the app, and scope_extensions are other things that can also be counted as in-scope to the app. This is the case for both the examples I gave - for example it wouldn't be appropriate to offer to open docs.example.com in the editor.example.com app, it just happens to be an additional scope of the app which actually lives at editor.example.com. However that appears to be the current design, which I don't think makes sense.

Perhaps the simplest solution is if there is both the option to show "open in app" and "install app", just show "install app".

I suppose others out there might have actual PWAs that truly operate across multiple origins, but that seems a weird thing to do - how would you manage permissions, storage, authentication and such? It seems to just be a way to make life a lot harder. If that is something people really do, then I guess we could do something like a separate allowed_navigations field (option 2), which I think is the same thing as you were getting at. But if in practice nobody makes truly cross-origin PWAs, I think it would be simpler to just say the primary scope is the app, and scope_extensions are extra places the app is allowed to navigate to but don't count as actually being the app (option 1). (But then maybe it should have been called allowed_navigations in the first place...)

Another idea is perhaps to add a "mode" field to entries in scope_extensions. The default could be "app" meaning the additional origins count as part of the PWA itself. A new option could then be added like "navigate" that allows navigating to those origins in the installed PWA without looking like they are out of scope, but not counting as the app for "install as app" or "open in app" purposes.

[mkruisselbrink]

The context in which partners requested the current scope extensions+link capturing behavior is for when a PWA is (in the process of) migrating to a different origin. In that case the secondary origin is really the new main origin and as such they want to keep capturing navigations to those URLs as well. But I agree that that is only one use case of scope extensions, and perhaps not the most common one.

[AshleyScirra]

Ah, OK, I guess that makes sense as a case where two origins may really be the same PWA. Perhaps we could have a separate set of allowed navigations then?