Notification permission requirement

[mkruisselbrink]

In step 4.2 of the setting the application badge algorithm, it is written that if a user agent requires express permission (and notifications permission hasn't been granted), they should jected with a NotAllowedError. As far as I know this isn't implemented by at least the one user agent I'm aware of that has this permission requirement (i.e. webkit), as both Navigator.setAppBadge and the equivelent WorkerNavigator code unconditionally resolve the returned promise with undefined.

But without that promise rejection, I'm not sure how websites are supposed to determine if they are required to request notifications permission in order to use app badging. Are we expecting site authors to do user agent sniffing (and try to come up with a complete list of user agents that have this requirement)?
Should there perhaps be a separate "is notifications permission required for app badging" API?
And if there are no user agents that actually implement step 4.2, should the step even exist in the algorithm?

[fallaciousreasoning]

I think if the user agent wants, they can show the required permission prompt when the app tries to set a badge, so websites shouldn't need to worry about requesting the permission separately. Was that what we intended here @marcoscaceres? Sounds like it might be worth cleaning up anyway

[mkruisselbrink]

For an API like this (which might be called in contexts where permission prompts can't be shown like service workers, or without user interaction) generally the user agent automatically showing a permission prompt doesn't work very well. Although it is one thing I am considering maybe doing. It would at least be better than user agent sniffing or unconditionally requesting permission...

[tomayac]

unconditionally requesting permission...

This is what the demo does now unfortunately.

[fallaciousreasoning]

Good point @mkruisselbrink - I've clearly been out of it for a while 😆

Hmm, definitely feels unideal that the demo is unconditionally requesting permission to show notifications - Is it a requirement now, that the notifications permission is granted?

[mkruisselbrink]

It's a requirement in Safari, and it might become a requirement in Chrome on MacOS (for the same OS reasons that it is a requirement in Safari I imagine).

[marcoscaceres]

We should go back and evaluate if we need to the permission check at all. On Apple's platforms, the badge being shown is controlled and determined by the OS through applications settings.

If the site tries to set the badge, the OS shows:

But the promise resolves because the badge is actually "set" but it's just not displayed.

If the user then grants the permissions above, the badge count appears.

So, I think it would be safe to remove the permission check related to notifications here, at least on the WebKit side (as we don't actually check the permission).

Generally, one wouldn't want to allow the site to check if it can set the badge, as it could then be used as a fingerprinting vector.

For frames that have not been granted a API access through a permissions policy, we should probably throw a NotAllowedError or something. (spec restricts to same origin)

[fallaciousreasoning]

That seems pretty sensible to me. Agreed that we shouldn't let sites check whether they're allowed to badge. I don't think Chromium checks for permissions at all.

[marcoscaceres]

Ok, so, on iOS / Safari 26, it's a bit different: the above still holds (the badge can be "set"), but it only becomes visible if Notification.requestPermission() is called and the user grants permission. Then badging is controlled through the OS settings.

So, we can still remove explicit permission check, I think. But we should have a note that calling Notification.requestPermission() is something one might need to do.

[marcoscaceres]

Just as an aside, I agree that it kinda sucks that granting the entirety of the "notifications" permission, which are super powerful (playing sounds, showing images, etc.) is not amazing in this case.

However, we could leave it to the OS or permissions UI to solve for this.