Scope of badging

[rowan-m]

A given domain can have multiple service workers and manifests with different scopes. For example, assume I have a:

• a service worker at /
• a manifest at /my-orders
• a manifest at /deal-of-the-day

Assuming a sync in my service worker like

self.addEventListener('sync', () => {
  self.Badge.set(latestOfferEmjoi());
});

Which installed manifest would get that badge?

My assumption would be that the badge inherits the scope of whatever's calling it. i.e. if the service worker is at / so both installed apps at the lower scope get the badge.

Could we have an optional scope parameter, similar to navigator.serviceWorker.register() that would allow setting the badge at a narrower scope? This would allow a top-level service worker to set a badge for a lower level installed app without affecting the other.

I think I would also expect any badge set at a higher scope to override any more specific ones.

[g-ortuno]

I believe that's what the TODO in the explainer is proposing as well:

TODO: An issue is that if the methods are called from a service worker whose
scope is a parent of the web app manifest scope, it would be ambiguous which web
app is being identified. We need to take an optional scope parameter.

[rowan-m]

Ah, shame cube time - didn't see that previously. Will leave this here in case there's more discussion to be had on the topic.

[mgiuca]

Thanks, Rowan. Yep, let's leave this open as it's something we still need to address.

Options, as I see it, are:

• Add an optional "scope" argument which lets you explicitly specify a URL. Apply the manifest within scope algorithm to find a matching manifest.
• Add an optional "manifest" argument which lets you explicitly specify a manifest URL. Match only the installed app with that manifest URL.

This ties into the debate about how to uniquely identify a manifest, in w3c/manifest#668 (we need to be able to map a manifest onto a specific instance of an app, which requires some concept of an app "primary identifier").

[fallaciousreasoning]

I think this is addressed by #39. We're proposing associating all badges with a scope as opposed to an app.