In my view, the ideal number of buttons is platform (and OS version) specific as it largely depends on their presentation. Influencers include whether or not button icons are visible, horizontal or vertical stacking and/or whether they're in a drop-down menu that may hide other functionality.

Based on the sort of cross-platform inconsistency problems that developers run in to for notifications, I would personally prefer providing more information rather than less. Maybe even carefully erring towards some sort of getCapabilitiesAndImageResolutions() call. Is there a particular fingerprinting association that you're worried about that couldn't be derived from the user agent?

The other problem with this feature, and actions in general, is that it seems there's only one implementation.

I would love to learn why other vendors haven't implemented support for actions. We're seeing that >5% of desktop and >10% of mobile notifications includes at least one.

I'm implementing actions in Firefox and I find it impractical to retrieve the actual max number of actions via a synchronous attribute, on top of the fingerprinting concern mentioned here.

Chrome returns 2 everywhere, Firefox will most probably do the same. Maybe the spec can also just define it as constant.

You don't think not exposing it at all is an option? With only one implementation we could just remove it.

We'll have some limitation for the number of actions, wouldn't it be confusing to silently show only the first few actions without exposing actual max number?

I'm not really sure how to reconcile that statement with the idea that the specification can just define it as a constant. If it's always going to return 2, people will know they can have two actions (and maybe more). They don't need that attribute for that.

Ah okay, if we go that route, I'd also vote to throw for extra actions rather than simply ignore as the current spec says:

For each entry in options["actions"], up to the maximum number of actions supported (skip any excess entries):

If it'll be 2 everywhere then we don't really get anything by silently ignoring, it only becomes a footgun.

Edit: But the current validation steps for other fields also just ignore invalid values...

An alternative that might work is that it returns 2 until permission is granted, at which point it can return the accurate number.

Mozilla would be fine with that approach, although we still need to add an async function to get the accurate number.

Just to note: Currently platforms do not provide an API for browsers to query about the max action count. It's all hardcoded: Android says 3, Windows says 5, and macOS says 10, and not even sure whether it's documented at all for Gnome/KDE/other Linux desktop environments. And all of these may be different based on their versions.

I'm not sure why we'd need an async function.

To query the system about the limit?

Why wouldn't you just run the maxActions getter again once the permission state changes?

You mean you want to make Notification.permission pass the maxActions too? 🤔

I'm not sure what you mean. The user agent can update things as part of there being permission. One such thing can be the internal slot for maxActions.

But the sole purpose of that would be just to return it through Notification.maxActions, not sure that's more practical than having Notification.getMaxActions that does it on-demand.