RESOLVED INVALID254884
setAppBadge() with no or '0' as argument should show badge
https://bugs.webkit.org/show_bug.cgi?id=254884
Summary setAppBadge() with no or '0' as argument should show badge
ik
Reported 2023-04-02 03:43:00 PDT
According to MDN, calling setAppBadge() with no arguments or '0' should display a badge without a number. Instead, both setAppBadge() and setAppBadge(0) will show no badge (or remove it if it was called with a number before) Relevant MDN documentation: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/setAppBadge#parameters (Wasn't sure which component this belongs to so I chose 'New Bugs')
Attachments
Marcos Caceres
Comment 1 2023-04-03 18:45:58 PDT
Right. iOS doesn't support the notion of a "flag" (calling setAppBadge() with no arguments) so the behavior is expected. However, calling setAppBadge(0) clears the badge (i.e. same as calling clearAppBadge()). Makes sense?
Marcos Caceres
Comment 2 2023-04-03 20:57:26 PDT
So yeah, MDN is wrong. It should say that "On some operating systems, ...". There is nothing in the standard that guarantees any badge (number or "flag") will be displayed at all. Similarly, Android doesn't support displaying numbered badges... in fact, on Android, a badge indicator is only shown is a visual notification is displayed (and the badging API has no effect even though it's exposed).
ik
Comment 3 2023-04-04 00:01:30 PDT
Thanks for looking into this. I agree that MDN is wrong, there is a difference between passing '0' ("nothing') or no argument ("flag") to setAppBadge. The spec: https://w3c.github.io/badging/#setting-the-application-badge https://w3c.github.io/badging/#dfn-flag - Calling setAppBadge(0) (the value "nothing") should remove the badge. WebKit does this correctly, MDN is wrong. - Calling setAppBadge() (the value "flag") should display a badge without a number. WebKit incorrectly removes the badge. I do agree that iOS not supporting "flag" badges presents a problem here, but I'm not sure that removing the badge is the right solution? Maybe showing '1' is more appropriate? I'd rather have WebKit handle this because the alternative is that websites need to call setAppBadge() or setAppBadge(1) depending on browser detection (which is undesirable).
Brady Eidson
Comment 4 2023-04-04 18:02:10 PDT
(In reply to ik from comment #3) > > - Calling setAppBadge() (the value "flag") should display a badge without a > number. WebKit incorrectly removes the badge. WebKit actually doesn't (see below) > I do agree that iOS not supporting "flag" badges presents a problem here, > but I'm not sure that removing the badge is the right solution? I agree that `setAppBadge()` - An attempt to set the badge to flag - should not remove the badge. That's a bug. > Maybe showing '1' is more appropriate? I don't think "1" meaning two very distinct things is a great situation to be in. > I'd rather have WebKit handle this because the alternative is that websites > need to call setAppBadge() or setAppBadge(1) depending on browser detection > (which is undesirable). I don't think that websites that want to set `flag` would be happy with `1` instead. It seems like maybe you would be, but are you saying it's the right thing to have the platform enforce that for all websites? I don't think that's obviously right. That said, WebKit actually isn't the business of doing anything here. WebKit communicates all of the information properly through its delegates and the embedding app makes the call of what to do. There's *definitely* a bug in Apple's iOS 16.4 release in that attempts to set `flag` instead clear the count. And an Apple component should be updated to fix that. We'll import into Radar to get the ball rolling there.
Radar WebKit Bug Importer
Comment 5 2023-04-04 18:02:24 PDT
Marcos Caceres
Comment 6 2023-04-04 18:26:00 PDT
Filed an issue on the spec also to provide some guidance: https://github.com/w3c/badging/issues/102 (and also clarify how to handle bug where numbers are supported but flag isn't)
ik
Comment 7 2023-04-04 21:29:15 PDT
Thanks!
ik
Comment 8 2025-10-07 06:30:06 PDT
Looks like this can move forward? > [...] user agents should handle cases where the operating system does not support certain badge types. User agents must preserve the semantic intent of the badge (flag vs. nothing) and use the closest available representation, but must never clear the badge when a flag is requested. https://github.com/w3c/badging/pull/123 Thanks again for following this up @marcos !
Note You need to log in before you can comment on or make changes to this bug.