Browser MUST always display a permission prompt after a user interaction
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- html
- 領域
- api
調査の方向性
Start by reading the issue’s request to require browsers to show a permission prompt after explicit user interaction, along with the linked reproduction site. The issue does not name a specification section, source file, or test to begin from; identify the relevant Push API standard text and tests before proposing a change. Done means the standard clearly states the requested behavior and the test coverage reflects it.
索引モデルが issue の本文から書いたものです。
説明
I would like to report an "abusive" behavior of some versions of Chrome on mobile.
A few years ago it was said that displaying a "permission prompt" directly on page load is not a good practice.
The recommended solution - even in Google UX guides - was to explain to the user the purpose of the notifications using HTML, CSS and then if the user explicitly clicks "Subscribe" then show the actual permission prompt.
Now I have seen on a specific version of Chrome on mobile that Chrome automatically blocks the notifications even on a website that has always respected the UX requirements (e.g. double permission prompt).
This is what happens:
- The user wants to subscribe to the notifications and clicks "Allow" on the first prompt (designed with HTML + CSS)
- The user should now see the actual permission prompt to confirm the choice... but Chrome automatically blocks the notifications without asking to the user.
This is a terrible user experience and makes it really hard for a user to subscribe to the notifications, even on legit websites that follows the best practices.
Please clarify in the standard that a browser MUST display the permission prompt after an explicit user interaction (e.g. click on a button).
Note: you can reproduce the described behavior on the latest versions of Chrome on mobile on https://blog.pushpad.xyz for example.
- 主要言語
- HTML
- スター
- 158
- フォーク
- 43
- 平均マージ
- 2日 6時間
- マージ済み PR（30日）
- 2
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
w3c/push-api のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
-
Do we want to allow a subscription from window.pushManager to fire push event for non-DWP messages?オープン
難易度 5/5 1週間以上 初心者へのやさしさ 18/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
zold-io/wts.zold.io#620 ·
メンテナーはふだん 1 日以内に返信
-
bug file-compat priority: medium
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
storytold/wordcraft#6209 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
-
backlog multiple issues priority: low
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
storytold/pdfcraft#6911 · コメント 2 件 ·
メンテナーはふだん 2 日以内に返信