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')
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?
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).
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).
(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.
<rdar://problem/107639557>
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)
Thanks!