Issue metadata
Sign in to add a comment
|
Notification.permission wrong value for notifications automatically blocked by the browser
Reported by
marc.gar...@marfeel.com,
Aug 2 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Go to one site with PushNotifications, for instance https://onesignal.com/ 2. close notifications requests using the top cross until they're blocked automatically by the browser. If you're testing on onesignal.com, click on the bottom bell for asking for notifications permission. 3. Check Notification.permission on the console, it will be "default" instead of "denied" What is the expected behavior? Notification.permission should be "denied" instead of "default". What went wrong? Notification.permission is returning "default" but notifications are blocked. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: n/a OS Version: OS X 10.12.3 Flash Version:
,
Aug 2 2017
Thanks for the report. This was fixed in Chrome 60 in issue 730273 . Now when permission requests are temporarily blocked due to multiple dismissals, they will return "denied". (note however that there are no easy ways of distinguishing this from cases where the user permanently blocked the permission, other than checking the permission again later/in another execution context where the temporary block no longer applies) |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rsesek@chromium.org
, Aug 2 2017