Badge permission...

[marcoscaceres]

For installed apps, showing badges makes sense, because of the song-and-dance the users have to go through to install a web apps. However, I wonder if we need to gate the API using a permission to mitigate tabs unnecessarily drawing the user's attention?

This could potentially be handled at the UI layer... just putting this here for discussion.

[fallaciousreasoning]

I think we might not need to worry about this. Web sites can already show a badge through the favicon/title hacks. If we did add a permission it might just encourage sites to keep doing whatever it is they're currently doing, instead of using the new API.

In addition, because the API is fire and forget, user agents could show a permission prompt the first time an origin/scope/page requested to set a badge (if they so chose) with the current API. I guess we could update the spec to say user agents MAY choose to ignore badge requests but I'm not sure we need anything more than that.

[marcoscaceres]

ok, but Badge is a little different. Imagine from a11y perspective (where it is announced), or even at visual level, where do want to draw a little more attention than a fav icon can do. I guess I need to experiment a bit and talk to our UI folks... no need for us to take any action here, just preempting some potential discussion down the road.

[mgiuca]

I don't think this needs to be exposed through the permission API (since it's transparent / fire + forget), we don't need to expose to the site whether it has the badge permission. There's no behaviour you could change if you didn't have the permission.

I think we just note this in privacy section that UAs can add permission UI for it. (And it would only apply to the client API for non-installed sites; I think it's quite reasonable for an installed app to show badges without permission, though others may disagree. I think iOS lets users switch off badge permission for native apps.)

[marcoscaceres]

I think we just note this in privacy section that UAs can add permission UI for it.

Yeah, that would be fine.

[othermaciej]

I think there should be a badge permission. Native operating systems that support basing often gate it on a permission, same as notifications. It might even be reasonable to share a permission with notifications.

Since there is a common framework for requesting permissions on the web, I think the spec should write out how requesting permissions would work, and note that UAs are allowed to grant the permission automatically without asking the user.

[othermaciej]

I'll further add, even if permission is granted by default, it seems good for browsers to give the user a way to deny badging permission after the fact, and integration with Permissions would provide a way to express this.

[marcoscaceres]

In agreement with @othermaciej (#44 (comment)), badging is inherently tied to the "notifications" permission. The spec should check if the document is allowed to use "notifications", and reject appropriately if it's not.

That would mean that script should call Notification.requestPermission() before calling setAppPermission(), and setAppPermission() should only succeed if the permission is "granted".

[fallaciousreasoning]

I think having a permission is fine, but I don't know if we should tie it to the Notification permission. Notifications are pretty invasive, whereas a badge can just fade into the background. For example, for Instagram, I normally disable notifications (because there are a lot) but let the badge display (so I don't open it unless something has happened).

In addition, I think this would make it hard for the Chromium implementation to stick to the spec. When I worked on it (I'm not at Google anymore), we wanted to be able to display the Badge without a permission prompt, and that'd be difficult if it were gated on Notifications.

Disclaimer: I don't work on this anymore, and I don't work at a company which works on this. Just commenting because I still follow the API in my own time 😄

[marcoscaceres]

Really appreciate your input @fallaciousreasoning, even if you are no longer working on this.

I think having a permission is fine, but I don't know if we should tie it to the Notification permission

On iOS at least, badging is tied to notifications. So, even if Android auto-grants it, that's not possible to set a badge on every OS without getting ("notification") permission (note the wording of the permission, which explicitly calls out "icon badges"):

Notifications are pretty invasive, whereas a badge can just fade into the background.

I don't think that's a view that's shared universally (there is a good book called "stolen focus" about this from a user's perspective - great xmas reading!🎄). On iOS, and a lesser degree on macOs, they are treated as equally as invasive as any other notifications.

I think this is also true on Android, to a degree: in Android's settings, I can see that "Notification dot on app icon" is controlled from the Notifications panel too (even if badging is enabled by default).

In both cases, it's recognized as a "notification".

and that'd be difficult if it were gated on Notifications.

It could be that, for instance, we could have a permission descriptor like: {name: "notification", type: "badge"} which is auto-granted. That would allow badging to work seamless on Android and other OSs where permission is not needed.

For example, a developer could then check the following hypothetical Permission Descriptor:

const {state} = await navigator.permissions.query({name: "notification", type: "badge"});
if (state === "granted") 
   await navigator.setAppBadge(1);

we wanted to be able to display the Badge without a permission prompt, and that'd be difficult if it were gated on Notifications.

Apparently it used to be possible to set a badge without permission prior to iOS 8, but no longer. So, there is no way around it on Apple's platforms at least.

Checking on Android, the API is exposed but it doesn't do anything :(
Maybe this only shipped on Chrome OS?

It works well in Edge.

[fallaciousreasoning]

Wow, I didn't realise it was supported on Android at all :O Last time I checked in Android didn't provide any API for doing this.

But that sounds reasonable, as long as there's a way to tell Badge notification requests apart from others (even if we don't end up doing anything different for them, it means we won't paint ourselves into a corner).