Browser MUST always display a permission prompt after a user interaction
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- html
- Lĩnh vực
- api
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- HTML
- Star
- 158
- Fork
- 43
- Merge trung bình
- 2 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 2
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của w3c/push-api
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
-
Do we want to allow a subscription from window.pushManager to fire push event for non-DWP messages?Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 18/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 12/100
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
zold-io/wts.zold.io#620 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug file-compat priority: medium
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
storytold/wordcraft#6209 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
-
backlog multiple issues priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
storytold/pdfcraft#6911 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày