Relationship between nestedly scoped web app manifests?

[Huxpro]

There is an explicit section match-service-worker-registration defining how nestedly scoped service workers work, where a SW with longest scope_url would "override" all the others:

5. Set matchingScopeString to the longest value in scopeStringSet which the value of clientURLString starts with, if it exists.

But of web app manifest, how nestedly scoped web app (manifest) effect with each other? Taking / and /sub-app/ as an example, is the one with shorter path (which has a wider scope) totally bypassed? OR the longer-path one (the sub one) can inherit all missing members from the shorter/parent one? There seems no definition exist about this scenarios in the current spec.

Furthermore, there might exist some scenarios that a /sub-app/ want treat / as sort of "parent app", where the sub-app can be navigated to from the "parent app" (in current browsing context) but has its own needs for a separated manifest (e.g. different themes/bg colors, different orientation, different desceiption etc. I think It's common?), thus should allow the navigation back from sub-app to "parent app".

There might be more complicated scenarios in practice, I believed It's worth discussion ;)

[RobDolinMS]

This is the first I'm hearing of potentially nested manifests.

Is this a theoretical question or are there examples of sites that implement this functionality? Are there web browsers / user agents that support such functionality?

Considering a complex web app manifest is still a relatively small JSON file with around a dozen top-level members, I wonder how much demand there is for something like this.

[Huxpro]

Well, let's take Alibaba as a example.
You might have heard about Alibaba's Taobao.com? The biggest e-commerce site of China.

The URL of Taobao mobile web app is h5.m.taobao.com/;
In the meantime, a separate web app named AliTrip is under h5.m.taobao.com/trip/home/ ;
Moreover, some sub-apps of Alitrip are under h5.m.taobao.com/trip/whatever/ ;

What if Taobao and Alitrip want to build their own PWA without altering the domains? And what if users want to add those sub-apps of AliTrip independently? (I mean, they are hotel booking, airplane ticketing thus It totally make sense.) That will make nested manifests happen.

[kenchris]

That sounds a bit like Android apps being able to add multiple different home screen icons (still only one icon in launcher) for shortcuts into the apps, like for chats with a specific friends, weather for Google search, my apps for Google Play etc

[kenchris]

@Paul_Kinlan ^

[RobDolinMS]

This seems somewhat similar to the challenge(s) described with multiple scopes in #449

In the case @Huxpro describes, I'm thinking:

• Taobao PWA's manifest might use:

"scope":"h5.m.taobao.com/"
"start_url":"h5.m.taobao.com/"

• AliTrip PWA's manifest might use:

"scope":"h5.m.taobao.com/trip/"
"start_url":"h5.m.taobao.com/trip/home/"

• AliTrip "sub-app" PWA's manifest might use:

"scope":"h5.m.taobao.com/trip/whatever/"
"start_url":"h5.m.taobao.com/trip/whatever/"

If there was shared content or a shared log-in page that resided on the root h5.m.taobao.com, that the AliTrip PWA or the AliTrip "sub-app" PWA needed, issue #449 would enable adding that (ex: h5.m.taobao.com/login) as an additional scope.

[Huxpro]

@RobDolinMS Yep, glad to see the discussion!

I think the feature I mainly requested is pretty similar to

In another case, a web app (scope:Chat.Example.com) might have peer subdomains that are in-scope (scope:Music.Example.com and scope:Video.Example.com) but might also have peer domains that are out-of-scope (scope:Events.Example.com)

but focus on paths instead of subdomains. If we take something similar to the proposal of exclude from @benfrancis the manifests might look like:

• Taobao PWA's manifest might use:

"scope":"h5.m.taobao.com/"
"scope_exclude": ["/trip"],
"start_url":"h5.m.taobao.com/"
“stay_in_app": ["http://login.taobao.com"]

• AliTrip PWA's manifest might use:

"scope":"h5.m.taobao.com/trip/"
"scope_exclude": ["/sub-app1", "/sub-app2"],
"start_url":"h5.m.taobao.com/trip/home/"
“stay_in_app": ["http://login.taobao.com"]

• AliTrip "sub-app" PWA's manifest might use:

"scope":"h5.m.taobao.com/trip/sub-app*/"
"start_url":"h5.m.taobao.com/trip/sub-app*/"
“stay_in_app": ["http://login.taobao.com"]

In this case, the Alitrip sub-app PWAs could be separated from Alitrip PWA and AliTrip PWA could be separated from Taobao PWA. The browsers could open a new browsing context when navigating to Alitrip from Taobao PWA and vice versa.

[Huxpro]

But It is still kinda verbose and is slightly different from subdomains' issues cuz the path could be nested. Thus I do think taking advantages of allowing overriding might solve problems better.

For example, we could define some override rules like service workers: the manifest from longer path (a.k.a subManifest) always extend the one from shorter path (a.k.a superManifest):

• subManifest inherit all members undefined from superManifest
• subManifest override all members it defined to superManifest

In this case the manifests might look like:

• Taobao PWA's manifest might use:

"scope":"h5.m.taobao.com/"
"start_url":"h5.m.taobao.com/"
“stay_in_app": ["http://login.taobao.com"]
"theme_color": "orange"

• AliTrip PWA's manifest might use:

"scope":"h5.m.taobao.com/trip/"
"start_url":"h5.m.taobao.com/trip/home/"
"theme_color": "blue"

• AliTrip "sub-app" PWA's manifest might use:

"scope":"h5.m.taobao.com/trip/sub-app*/"
"start_url":"h5.m.taobao.com/trip/sub-app*/"

Pretty neat right?
And It seems accommodate most use cases related to path well ;)

[marcoscaceres]

Will deal this, if it's an actual bug, as part of the work we will do to close off any remaining scope member issues.

[Huxpro]

@marcoscaceres It's been a while since I opened this. Great to see there is follow-up going on!

[philloooo]

I have a simpler question to ask relating to this:
if a site has two manifests with scope / and scope
/sub-app/, when navigating to an URL, how does the user agent decides which app this URL belongs to?

Currently Chromium matches with the app that has the longest scope. So if both apps are installed, navigating to /sub-app/page in a tab will have a launch icon in the omnibox to direct user to launch sub-app.

Should this be clarified in manifest spec?

[dmurph]

There has since been some more literature on the chromium side about this:
https://web.dev/building-multiple-pwas-on-the-same-domain/
The conclusions here are:

• Separate origins: Recommended
• Same origin, non-overlapping paths: Not recommended
• Same origin, overlapping/nested paths: Strongly not recommended

When talking to web developers, we have never found any strong use-case or reason why developers needed nested apps. And thankfully now that an id field has been spec'd, if developers end up in this situation, they can easily change their start_url and scope to get out of it the nested situation. The only place this seem possibly a requirement is in the multi-apps [1] project, and the behavior here can probably be specifically spec'd if we need to.

I wonder if it's ok to start with just specifying what the current status quo is, and hopefully it's not-great nature will dissuade developers from doing this. Would the following help with resolving this issue?

Understanding "scope"

Web apps that share an origin.

There can be web apps that share an origin, where their scope contains the same origin. This is not recommended due to origin-based settings like:

• Permissions
• Storage and storage quota
• User settings (e.g. font size)

Web apps that have nested scopes.

Among the issues above, if a page resides inside the scope of multiple webapps, that is considered a scope conflict. This is strongly not recommended, and will cause the following possible UX changes and API behavior inconsistencies, among other possible issues:

• Installation prompting may not work for the nested app if the outer app is installed.
• User-agent UX around launching an app for a browsing context may be inconsistent or not appear.
• Badging API calls will not be able to consistently update the correct web app badge.
• Notifications may have incorrect attribution or not appear.
• Future APIs may not work at all in this configuration.

[1] https://github.com/ivansandrk/multi-apps/blob/main/explainer.md

[javadch]

Just to jump into the discussion:
In ERP systems, there is usually an empty shell with a basic layout, general functionality such as logging in, out, etc., and a set of so-called modules. These modules are packages of functionality that are usually developed by different teams and then deployed into the shell. They have their own manifests while they know an upper application exists that also has a manifest.
In this setting, some upper manifest elements such as the icon should be propagated to the shell and any module.
Elements such as title may be propagated and concatenated with that of the modules (if they exist). E.g., : in the title bar.
Some other elements such as theme and color, should be taken from the parent as default (fallback) but overridden by the modules (if they have matching elements with valid values.)
This is something I have been doing in a few applications that I have been designing or otherwise involved.
Thanks

[dmurph]

Closing due to how this doesn't affect user agents like Safari who are doing full isolated installs. Documentation about Chromium's recommendation is at https://web.dev/articles/building-multiple-pwas-on-the-same-domain