Browser MUST always display a permission prompt after a user interaction
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- html
- Ambito
- api
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- HTML
- Stelle
- 158
- Fork
- 43
- Merge medio
- 2g 6h
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di w3c/push-api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
-
Do we want to allow a subscription from window.pushManager to fire push event for non-DWP messages?Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 18/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 12/100
Tutte le issue di w3c/push-api
Issue simili
-
enhancement triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
ShaftHQ/SHAFT_ENGINE#7901 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ClickHouse/clickhouse-js#1130 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
DOI-USGS/pywatershed#428 ·
-
web_to_md writes image links with a backslash on Windows, so import-sources can't rename themAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
hugohe3/ppt-master#348 ·
I maintainer di solito rispondono entro 1 giorno
-
bug claude Minor static-analysis
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
linagora/cozy-flagship-app#1358 ·