这是这个问题的重复：
由于该帖子已关闭，我无法在那里评论。
这个问题仍然发生在我身上。
discourse-push-notifications v0.3.0
discourse v2.5.0.beta2
1 个赞
您使用的是哪个浏览器？浏览器版本号是多少？您是否尝试过在其他浏览器中操作？您是否尝试过禁用所有浏览器插件，使用干净、无修改的浏览器默认安装版本进行操作？
2 个赞
已在 Chrome 和 Firefox 中复现。
Chrome 版本 80.0.3987.149（官方构建）（64 位）
Firefox 74.0（64 位）
操作系统：
Ubuntu 19.10
也在无痕模式下尝试过，未安装任何扩展，结果相同。
附上一段短视频以作演示：
- 控制台无错误。
- 管理员日志中无错误（https://discourse.yoursite.com/logs）
后来发现了这篇帖子：https://meta.discourse.org/t/discourse-push-notifications-for-desktop/86941/49，其中描述了类似的问题。
1 个赞
我可以确认，此问题在 Windows 和 Android 系统的 Chrome 浏览器中均会出现。
1 个赞
我查看了切换开关并保存时的网络请求。
点击保存按钮时，会发起一个网络请求到：
PUT https://discourse.example.com/u/{user-id}.json
当开关为 ON 状态并保存时，发送的表单数据如下：
new_topic_duration_minutes: 2880
auto_track_topics_after_msecs: 240000
notification_level_when_replying: 2
like_notification_frequency: 1
allow_private_messages: true
当开关为 OFF 状态并保存时，发送的表单数据如下：
new_topic_duration_minutes: 2880
auto_track_topics_after_msecs: 240000
notification_level_when_replying: 2
like_notification_frequency: 1
allow_private_messages: true
如您所见，两者完全相同，“优先使用推送”选项似乎并未包含在内。
此外，检查本地存储（localStorage）时，我发现一个名为 discourse_push_notifications_prefer_push 的属性，在切换“优先使用推送”选项的开关时，该属性的值会在空值和 true 之间交替变化，但它似乎并未被添加到网络请求中。
另外，我手动在 Discourse 浏览器控制台中执行了 isPushNotificationsSupported 的评估，结果为 true，这意味着（我想）推送功能是受支持的……
我还要补充一点，“启用通知”按钮工作正常：
启用后我也确实收到了测试通知。
1 个赞
这是 @falco 的一个 bug 吗？
2 个赞
看起来确实如此。考虑到这并不是最常用的功能，移动端推送很常见，而桌面端通知更为普遍，而且我认为团队或我们的托管服务中没有人使用此功能，所以我并不感到意外。
我本周会尝试修复它。
2 个赞
好的，现在你把我搞糊涂了
你说的“桌面通知”是指这个设置吗？
我从一开始就启用了这些选项，但从未收到过任何浏览器通知：
- 当我首次登录 Discourse 时，顶部出现了一条消息，询问我是否要启用通知。
- 我选择了同意，弹出了原生的 Chrome 对话框，我点击了允许，同时在 Ubuntu 的通知区域也收到了提示。
- 然而，我从未收到过任何关于活动的通知。当我切换到 Discourse 标签页时，右上角的个人资料图标上会显示“1”，但我必须主动切换到该标签页才能知道这一点。这是预期的行为吗？
- 因此，我原本以为这个插件的作用就是让你在不处于 Discourse 标签页时也能看到活动通知。
所以我搞错了？我到底漏掉了什么？
困惑 
1 个赞
这现在已生效，并将在密钥迁移期间持续生效，同时 自动续订推送通知订阅。
2 个赞