userVisibleOnly should be standardized to match browser behaviour

未关闭
  • 哪里不对？
#313 12 条评论 8 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
文档
描述清晰度
描述清楚
活跃度
停滞
技术栈
html
领域
documentation

调研方向

Read the Push API sections linked in the issue: §7 on subscribe, §10.4 on receiving a push message, and §7.2 on subscription options. The issue proposes normative changes and coordination with the Web Notifications spec; first determine whether those changes have been decided. Done means the spec clearly defines userVisibleOnly and user-visible effects, including how user agents should respond when no effect occurs.

由索引模型根据 Issue 内容生成。

描述

bug

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.

主要语言
HTML
星标
158
派生
43
平均合并
2 天 6 小时
30 天内合并 PR
2

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

w3c/push-api 的其他 Issue

查看 w3c/push-api 的全部 Issue

相似的 Issue

更多 Documentation Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。