Profile default_content_setting_values for images not taking effect when --headless
Reported by
tasos.la...@gmail.com,
Nov 20 2017
|
||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Steps to reproduce the problem:
Set the following chrome_options via Seleneium when Chrome is in --headless mode:
prefs: {
'profile' => {
'default_content_setting_values' => { 'images' => 2 }
}
}
What is the expected behavior?
<img/> sources should not be requested, but this only works when not in --headless mode for some reason.
What went wrong?
<img/> sources are being requested.
Did this work before? N/A
Chrome version: 64.0.3269.3 (Official Build) dev (64-bit) Channel: beta
OS Version: Ubuntu 16.04
Flash Version:
Using ChromeDriver 2.33.506092 (733a02544d189eeb751fe0d7ddca79a0ee28cce4)
via selenium-webdriver (3.7.0) in Ruby 2.5.0-prewview1.
,
Nov 26 2017
Headless is not fully compatible with Chrome profiles. See, https://bugs.chromium.org/p/chromium/issues/detail?id=617931 One way of blocking image download is to set up Request interception through DevTools: https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-setRequestInterception I'll mark as working as intended. If you have a more specific feature request, please let us know! |
||
►
Sign in to add a comment |
||
Comment 1 by krajshree@chromium.org
, Nov 21 2017Labels: Triaged-ET Needs-Triage-M64 TE-NeedsTriageHelp