[w3c/push-api] userVisibleOnly should be standardized to match browser behaviour (#313)

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](https://w3c.github.io/push-api/#pushmanager-interface), "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](https://w3c.github.io/push-api/#receiving-a-push-message), 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](https://w3c.github.io/push-api/#pushsubscriptionoptionsinit-dictionary) 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/313