userVisibleOnly should be standardized to match browser behaviour

[mgiuca]

The current spec text does not actually require anything relating to user-visible actions, while browsers have all sorts of requirements around this concept. It currently only says this:

The userVisibleOnly member, when set to true, indicates that the push subscription will only be used for push messages whose effect is made visible to the user, for example by displaying a Web Notification.

"indicates that ... will only be used for push messages" suggests that this member is a hint passed from the site to the UA indicating how it intends to behave. Not only doesn't it require any specific action on the UA, it doesn't even suggest that the UA should do anything.

My understanding (based on a private email with @beverloo ) is that some browsers (e.g., Chrome) require userVisibleOnly (effectively making it a de facto requirement that sites set userVisibleOnly), and that many browsers (whether userVisibleOnly is set or not) impose some sort of penalty for sites that do not show a notification when receiving a push (the penalty could be showing a UA-generated notification or unsubscribing from push).

Contrary to that, it is reasonable for a developer reading this spec text to assume that both:

a) They can set userVisibleOnly to false (the default) and then receive pushes without showing a notification, and that
b) If they do set userVisibleOnly to true, it won't actually do anything, so perhaps it's fine to set it to true with the intention of showing a notification, but conditionally deciding not to show a notification in certain situations.

I understand the need to avoid mandating a particular UX in the spec, but I think the spec text could be worded a bit stronger and closer to reality.

How about:

1. Mandating that userVisibleOnly be set to true (and note that its existence is a historical artifact). Or even removing userVisibleOnly with the assumption that it's true.
2. Properly defining the set of actions that constitute a "user-visible effect" (at this time, just displaying a Web Notification).
3. Suggesting (via a SHOULD requirement) what the user agent should do in the event that the message did not make a "user-visible effect".

In more detail (assuming we won't delete userVisibleOnly for now):

• In §7, "The subscribe method", there needs to be an explicit step which rejects the promise if userVisibleOnly is false.
• A definition of "user-visible effect", possibly creating a "user-visible effect" flag, then adding to the Web Notifications spec "set the user-visible effect" flag.
• In §10.4, after "Then run the following steps in parallel, with dispatchedEvent," a step which checks if a "user-visible effect" was triggered during processing the event, and if not, saying that the user agent SHOULD take some action to either notify the user that non-user-visible pushes are occurring, or prevent future non-user-visible events from happening (for example, showing a notification, or removing the push registration).
• A non-normative summary of this in §7.2 where userVisibleEffect is described.

This way, the spec creates precise logic for detecting "non-user-visible pushes", and while it doesn't mandate a specific UX response, suggests that the UA take some punitive action in this case.

[collimarco]

Yes, userVisibleOnly needs a better spec.

For example I have just received this message from a customer:

[About Pushpad] Does your API allows to not show the notification if the website has focus?

My first reply was that silent push is not allowed... but then I found this and I am really confused:

https://developers.google.com/web/fundamentals/push-notifications/common-notification-patterns#the_exception_to_the_rule

Please clarify if that is really allowed and what exact actions are considered visible to the user.

[collimarco]

Note that the answer here will have a huge impact on the use of web push and on the load of push services: for example if you allow to send silent push when a website is open, someone could build an online chat based entirely on web push (without websockets).

[garygreen]

This would have a negative impact on our application as well.

We use silent push notifications in many legitimate ways which improve the user experience.

For example, as a way of clearing existing notifications that are no longer relevant, but have been sent to the device:

1. Push sent to their mobile device > (tag: "new-message-123" title: "You have a new message")
2. User reads message on their desktop PC - notification is no longer relevant
3. "Silent push" notification is sent which is handled by our SW to clear notifications that have a tag of "new-message-123"

In addition, notifications can no longer be relevant if, for example, we ban a nuisance accounts on our site. We would want any notifications that user triggered to no longer be sent to those devices, or if they have, we want them to be cleared.

A silent push notification is the only way to do this. As there is no way of revoking push notifications that have been sent. You have to implement this stuff in your own UX.

You could technically implement a "revoke-like" notification by using a collapse_key - updating the notification so that it converts it into a "silent" one, but who knows what rules this breaks. Also it doesn't help if the notification has already been sent and shown on the device.

As another example - when users toggle on push notifications in the settings area of our app, we configure the PushManager, setup the subscription etc - and in the process we send a "silent" push notifications which we use to verify if the device is able to receive push notifications - if the notification came through, we then enable it on the server. It's basically just a sanity check and for peace of mind to make sure they are actually able to receive our push notifications. We could technically display a notification, but it never occurred to us doing this silently in the background is a "bad" thing to do.

So in summary please don't blanket condemn silent push notification as some horrible nasty thing that apps do and inform users that something bad is happening. There are legitimate reasons why silent push notifications are beneficial to the end user.

It would make a lot more sense if it was more about volume/quota of some kind - how much notifications are being sent/received. If it's beyond certain thresholds, then let the user know.

[jimmywarting]

the required userVisibleOnly=true is nothing but annoying and it should be removed. I do wish to use "silent" push to keep the client in sync with a 3-way-data binding and unsubscribe to changes when leaving the site. I also do not want to create an active open web socket connection as some cloud providers (like heroku, cloudflare workers and google cloud functions and others) wish to forcefully determinate the connection to save resources if the connection last more than 30s. Anything over that and you have to pay a higher fee/plan or resort to some wide scaled AWS solution to handle thousand of websocket connections simultaneously that one server alone can't handle. Some server side solution also don't have web socket support as it's not event driven, like PHP

I would also like to do some p2p webrtc signaling between 2 peers that are online without having to spin up a websocket connection.

There is so much good stuff you can do with "silent" push but it is avoided b/c users have a tendency to block desktop notification and most often dismiss annpying prompt dialogs.
ppl associate desktop notifications as something annoying as they are sometimes are prompted directly upon visiting a site without much context. It sometimes show ads, or sends out push notification too frequently of something that you aren't interested in or don't have fine graned control over

i also totally agree with @garygreen about syncing notification across devices as some messages can be marked as read and then being totally irrelevant.

---

ppl can disobey "must show a desktop notification" as they are free to simply just update the site if it's visible to the user so it dose not need to show a desktop notification when the user is active on the site... userVisibleOnly do not provide any guarantee that developer is going to show a desktop notification.

there is a useful feature to only allow sending silent push only when the user is active on the site cuz updates will only be happening on the site when users are online. and ppl don't wish to have to see that annying prompt dialog
I would be totally fine with a really hard penalty/qouta-limit and only be allowed to make some few amount of silent web push when the user isn't on the site and if it meant that i could avoid having to prompt the user for showing desktop notification...

i do not think web push should be associated with desktop notification. Since silent push is a total other ball game.
web push !== desktop notification so i therefore do not think web push should require any special permission or prompting dialog. I do not think chrome no longer needs it's userVisibleOnly option any more as it already have a mean to limit quota/budget on silent web push. developer are going to want to request permission to desktop notification in order to keep sending web push while the user is "offline"

I'm more okey with await swReg.pushManager.subscribe() throwing an error b/c you haven't requested permission to show desktop notification yet then it is to have to pass in a dum flag userVisibleOnly: true

I really think it should be fleshed up into two different things. desktop notification should not have to anything with web push:es.

it should rather be a way for "desktop notification" to reset the amount of web push:es you are allowed to send when user isn't on the website itself
And i should be able to silently subscribe to push without any prompting and be able to use silent web background push:es when the user is active on the page.

that way i don't need any consistent open WebSocket to 1000 ppl each using a different port and only being idle for the most part when there isn't any data being sent (i only keep it open in case if i need to send something)

the hole prompting dialog for sending out silent push (and only if the user is online) is only going for the most part be rejected as most ppl associate push notifications as something annoying on the web.

I genially would consider allowing more web sites to actually using silent web pushes if i'm being active on the page and was prompted and aware as they are not as annoying as push that requires a visible notification. but i would rather wish that they didn't prompt anything at all and only functional while being active on the site. (seeing it as mostly a short session subscription)

[SephReed]

Liking a lot of what others are saying. To throw in my 2 cents succinctly:

What was the intention with userVisibleOnly? I don't understand the goal yet.

Right now, it seems like it might not be needed. NotificationAPI already handles the permissions, and I'm missing any meaningful security differences between PushManager and WebSockets.

[collimarco]

@SephReed There's a big difference between PushManager and WebSockets: one can only work when a website is open, while the other can be activated in background. That's why userVisibleOnly exists: in order to prevent a website from running in background without the user noticing that.

[jimmywarting]

I for instance only want to use background push while the user have a tab open to my domain (to avoid having to create WebSockets) Chrome accepts silent push if the user is active on your domain. but it requires a darn prompt for desktop notification to allow it - which most ppl will block anyway so i can't really use it for anything good.

I know when ppl leave the site, so i will not send a push notification then.

[elf-pavlik]

Based on this information, iOS will revoke the push subscription if the application fails to show the notification.

https://meta.discourse.org/t/ios-notifications-can-lose-permission-to-push-if-the-user-is-currently-active/290225

It requires use of

self.addEventListener('push', (event) => {
    event.waitUntil(self.registration.showNotification('title', {
      ...
    }));
}

[collimarco]

@elf-pavlik All the information linked in your post seems really old (WWDC 2022), not something new. Are you posting it here because you have seen some new announcements or changes from Apple?

[elf-pavlik]

I came across the post I linked and this issue while trying to find the details about the implications of userVisibleOnly and if any form of silent push is possible. Since this issue concerns matching browser behavior, having some references for the current behaviors seemed helpful. The discussion I linked to, also seems to answer the question asked in #339. That issue also references a paragraph on MDN mentioning Firefox using a quota-based approach. Is there a good reference documenting the current behavior across all the major browsers?

[collimarco]

@elf-pavlik You cannot use silent push, it was never allowed. I wrote about it years ago and nothing changed in the meantime.

[saschanaz]

Never allowed in Safari/Chrome you mean?