Issue metadata
Sign in to add a comment
|
When notification permission is embargoed, requesting code cannot identify this state
Reported by
benl...@mobify.me,
Jun 29 2017
|
||||||||||||||||||||||||||
Issue descriptionChrome Version : 59 What steps will reproduce the problem? (1) Call Notification.requestPermission twice, dismissing the prompt (2) Call Notification.requestPermission one more time. The browser will embargo the request, and the Promise returned will resolve to 'denied'. The value of Notification.permission will still be 'default' What is the expected result? Either the Promise should reject because the request is embargoed, or the value of Notification.permission should be something other than 'default'. Currently there does not appear to be any way for code to know that a temporary embargo is in effect, and to detect when that embargo ends, so that it may ask for permission again. What happens instead? The Notification.permission will stay at 'default' but the result of Notification.requestPermission will always be 'denied'.
,
Jun 29 2017
,
Jun 29 2017
Thanks for the report. This is fixed in Chrome M60 beta - when embargoed, Notification.permission will not say "default" any more. |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by benl...@mobify.me
, Jun 29 2017