Headless Chrome is not respecting notification content settings?
Reported by
i...@appboy.com,
Sep 1 2017
|
||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36
Steps to reproduce the problem:
1. Launch Chrome with --headless. Give it a --user-data-dir to a directory which contains a Default/Preferences file with the following contents:
{"profile":{"content_settings":{"exceptions":{"notifications":{"https://localhost.ssl:9877,*":{"setting":1}}}}}}
3. Navigate to https://localhost.ssl:9877
4. Notification.permission will return "denied"
What is the expected behavior?
Notification.permission should be "granted" given when the content setting preferences are set to allow notifications. If I use the same user directory and launch Chrome directly (i.e. non-headless), and navigate to that same url, clicking to the left of the URL bar shows that Notifications are set to "Always allow on this site" as expected.
What went wrong?
Notification permission was still reported as denied though it had been granted.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 62.0.3198.0 Channel: dev
OS Version: OS X 10.12.0
Flash Version:
,
Sep 1 2017
You'll also need a site to actually be responding at https://localhost.ssl:9877 for this repro case to work, sorry for missing mentioning that in the repro steps above. I imagine it should repro similarly with other urls as well.
,
Sep 4 2017
Thanks for the report! This is WAI for now: profile notification settings live in chrome/browser, and headless does not pull dependencies form chrome. The proper way to handle this would be through DevTools commands, but afaik there are no command right now to handle permissions.
,
Sep 5 2017
OK, thanks for the context on that |
||
►
Sign in to add a comment |
||
Comment 1 Deleted