Add app badge to Declarative Web Push

[annevk]

To land this w3c/badging#111 needs to be completed. I'd like some help with that. @marcoscaceres maybe?

---

The following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementation support:

• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)
• WebKit

---

Preview | Diff

[marcoscaceres]

See w3c/badging#116

[marcoscaceres]

@annevk, to kick this off:

• I sent a PR to add "set the application badge for installed web application" to the badging spec (no platform object needed)
• In a hand-wavy way 👐, the spec checks if the "web application" is an "installed web application", and gets its "identifier" (a URL).
• Once it has the identifier, it uses that to set the badge number for the installed web application.

happy to refine from here... but it's broadly what needs to happen, right?

[marcoscaceres]

Just noting that not all platforms support setting a number: for instance, Android allows setting the badge to "flag" (which just shows up as a dot). Some macOS apps do this too (e.g., Slack).

For backwards compat, we might need to default change the badging API to support an enum to explicitly set a "flag" as the default value, so that:

• setAppBadge() - "flag"
• setAppBadge(0) - clear
• setAppBadge(N) - number.

[annevk]

So you're saying that even platforms that do render a number, can also render just the badge without the number? In that case we'd indeed need to support that separate state. We could perhaps allow passing undefined or null for that? Bit finicky, I'll admit.

[marcoscaceres]

So you're saying that even platforms that do render a number, can also render just the badge without the number?

Correct. Android in particular supports both modes ("App Icon can Show Badges with Numbers or Dot-style Badges"). Even though it's user controlled, a web developer can still just set a "dot" (i.e., what in the Badging spec is called a "flag").

Bit finicky, I'll admit.

Yeah :( hopefully we can do it consistently across both specs.

Possibly the most compatible option would be to change app_badge to support either a boolean or a 64-bit unsigned integer:

1. If app_badge is missing: do nothing.
2. If app_badge === true: then "flag.
3. Else if app_badge === false: "clear" (treat at 0).
4. Else if typeof app_badge == "number", set number.

We can distinguish between the types, so could potentially work.

[annevk]

That shape sounds good. What happens for platforms that don't support "flag" though?

[marcoscaceres]

Described in w3c/badging#123

[annevk]

@marcoscaceres we need a hook for this similar to "has showNotification() been successfully invoked". People were not happy with this being defined in a hand-wavy way.

[marcoscaceres]

IIUC, in the case of notifications, it emulates calling showNotification()...

Instead, for the Badging case, can we reuse "set the application badge for an installed web application" and I can get that to return a boolean if it worked?

[annevk]

No, this is specifically to catch the case where the developer used setAppBadge() (and maybe even clearAppBadge(), come to think of it) and so we don't want to use the declarative app badge result.

See https://notifications.spec.whatwg.org/#service-worker-registration-has-shownotification-been-successfully-invoked and how showNotification() ends up setting it to true. (We set it to false here first before dispatching the event to the service worker.) We need the same for app badge.

[marcoscaceres]

ah, ok... I'll have another look.

[annevk]

We should use |subscription| here, I think? Maybe

If appBadgeSet is false and |subscription| has an associated installed web application:

[annevk]

Though it would be nice to also support this outside of installed web applications. But I suppose that's a separate change.

[marcoscaceres]

Setting a badge is pretty tightly bound to installation at the moment, as that's how it's been implemented by everyone. We could change this if this changes.