New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 775911 link

Starred by 16 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocked on:
issue 617931



Sign in to add a comment

missing accept_languages in request for headless mode

Reported by dymo...@gmail.com, Oct 18 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
1. I'm trying to run some tests using headless mode so I set "intl.accept_languages" to "pl, fr, ru, it" and also added argument "--headless"
2. When the request comes from browser to server I see that value "accept_languages" in request header does not exist.

When I try to run the same test without headless mode accept_languages in header looks as expected.

What is the expected behavior?
headless mode should provide previously set accept_languages

What went wrong?
missing accept_languages in headless mode

Did this work before? No 

Chrome version: 62.0.3202.62  Channel: stable
OS Version: 8.1
Flash Version: 

Here's how i make configuration:

SeleniumWebDriver.Bootstrap(SeleniumWebDriver.Browser.Chrome);
var containerRegistration = FluentSettings.Current.ContainerRegistration;

FluentSettings.Current.ContainerRegistration = container =>
{
	containerRegistration(container);

	var driverPath = EmbeddedResources.UnpackFromAssembly("chromedriver.exe", Assembly.GetAssembly(typeof(BaseTestConfigurator)));
	driverPath = Path.GetDirectoryName(driverPath);

	if (_browserChromeOrderCulture != null)
	{
		chromeOptions.AddUserProfilePreference("intl.accept_languages", $"{_browserChromeOrderCulture}");
	}

	if (TestsEnv.UseChromeHeadlessMode)
	{
		chromeOptions.AddArguments("no-sandbox", "headless", "disable-gpu");
	}

	container.Register<IWebDriver>((c, o) => new ChromeDriver(driverPath, chromeOptions));
};
 
Components: Tests>WebDriver Internals>Headless
Hi,

What is $"{_browserChromeOrderCulture}" in the included code? Can you add the definition?

Comment 3 by dymo...@gmail.com, Oct 19 2017

Hi,

_browserChromeOrderCulture has "pl, fr, ru, it" value.

Comment 4 Deleted

Labels: -Needs-Feedback
Cc: vamshi.k...@techmahindra.com
Labels: TE-NeedsTriageHelp
Blockedon: 617931
Status: WontFix (was: Unconfirmed)
Chrome Preferences are currently not read in headless, since they don't share that codebase. That might change once https://bugs.chromium.org/p/chromium/issues/detail?id=617931 is resolved
Cc: headless-dev@chromium.org johnchen@chromium.org
 Issue chromedriver:1925  has been merged into this issue.
Cc: khachatryan@chromium.org
 Issue chromedriver:2154  has been merged into this issue.
Now that https://bugs.chromium.org/p/chromium/issues/detail?id=617931 is resolved, is there any chance that support for preferences in headless might be revisited?

Our use case is e2e testing involving UI that depends on notification settings. We're currently allowing notifications via:
'profile.managed_default_content_settings.notifications': 1

but this is not currently supported in headless and blocking us from switching.
+1 on reconsider allowing profiles for headless.  We're attempting to test pages that download files and being able to set the default download directory in a profile would be very helpful.
#11: See bug 696481 and  bug 831887  for download support via DevTools. Right now, you can use Page.setDownloadBehavior to set the default download path.

https://chromedevtools.github.io/devtools-protocol/tot/Page#method-setDownloadBehavior
Also, you can use --user-data-dir to override the profile directory itself.
still can not add profiles in headle mode?

Sign in to add a comment