Fixed
Status Update
Comments
mi...@gmail.com <mi...@gmail.com> #2
[Comment Deleted]
mi...@gmail.com <mi...@gmail.com> #3
[Comment Deleted]
mi...@gmail.com <mi...@gmail.com> #4
Sorry, the title should be "Setting UserDataDir via Windows registry breaks ChromeDriver 2.40" and the first sentence should not be part of the description. I seem to not have right to edit this.
kh...@chromium.org <kh...@chromium.org> #5
I fixed the title.
UserDataDir you should be added from Chromedriver options.
options.addArgument("user-data-dir=<path>")
UserDataDir you should be added from Chromedriver options.
options.addArgument("user-data-dir=<path>")
jo...@chromium.org <jo...@chromium.org> #6
On Windows, the UserDataDir can be overridden by either HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\UserDataDir or HKEY_CURRENT_USER\Software\Policies\Google\Chrome\UserDataDir. When both registry paths are used, the former appears to take precedence.
Overriding UserDataDir causes the DevToolsActivePort file to be created at a location no expected by ChromeDriver. Also, any preferences settings created by ChromeDriver would be stored at the wrong location, and ignored by Chrome. Another side effect is not able to launch multiple instances of Chrome, since two instances can't share the same UserDataDir.
I suppose ChromeDriver could read the registry to find out where the UserDataDir is, but that can be error prone. If possible, please don't override UserDataDir through registry while using ChromeDriver. If the setting is forced by some enterprise policy, there are several options:
* Use options.addArgument("user-data-dir=<path>") to tell ChromeDriver where the UserDataDir is, as suggested by khachatryan@chromium.org inhttps://crbug.com/chromedriver/2513#c4 .
* Use ChromeDriver 2.38.
* Wait for ChromeDriver 2.41, which will allow you to control the DevTools port.
Overriding UserDataDir causes the DevToolsActivePort file to be created at a location no expected by ChromeDriver. Also, any preferences settings created by ChromeDriver would be stored at the wrong location, and ignored by Chrome. Another side effect is not able to launch multiple instances of Chrome, since two instances can't share the same UserDataDir.
I suppose ChromeDriver could read the registry to find out where the UserDataDir is, but that can be error prone. If possible, please don't override UserDataDir through registry while using ChromeDriver. If the setting is forced by some enterprise policy, there are several options:
* Use options.addArgument("user-data-dir=<path>") to tell ChromeDriver where the UserDataDir is, as suggested by khachatryan@chromium.org in
* Use ChromeDriver 2.38.
* Wait for ChromeDriver 2.41, which will allow you to control the DevTools port.
mi...@gmail.com <mi...@gmail.com> #7
Good point, this is possible work-around: I can set the user data dir in the Chromedriver options to the exact same value as it is specified in the registry.
options.addArgument("user-data-dir=<same_path_that_is_specified_in_registry>")
This works for fine for one ChromeDriver. When I want to use muliple ChromeDrivers in parallel the second one fails with “unknown error: DevToolsActivePort file doesn't exist”.
I have the following scenario: The sys admin defines a group policy for user data dir for Chrome and rolls that out to all the Windows machines in his organization. The Selenium user (probably a different person) has a hard time to test multiple Chrome instances in parallel with ChromeDriver on such a machine.
options.addArgument("user-data-dir=<same_path_that_is_specified_in_registry>")
This works for fine for one ChromeDriver. When I want to use muliple ChromeDrivers in parallel the second one fails with “unknown error: DevToolsActivePort file doesn't exist”.
I have the following scenario: The sys admin defines a group policy for user data dir for Chrome and rolls that out to all the Windows machines in his organization. The Selenium user (probably a different person) has a hard time to test multiple Chrome instances in parallel with ChromeDriver on such a machine.
jo...@chromium.org <jo...@chromium.org> #8
When there is a group policy overriding user data dir, it's not possible to run multiple instances of Chrome, since Chrome is not designed to share the same user data dir among multiple instances. It would create many race conditions that Chrome isn't designed to handle. Unfortunately, this is a inherent design limitation of Chrome.
Maybe you can try to ask the sys admin to exclude the policy from the machine that requires running multiple ChromeDriver in parallel.
Maybe you can try to ask the sys admin to exclude the policy from the machine that requires running multiple ChromeDriver in parallel.
mi...@gmail.com <mi...@gmail.com> #9
Thx for the clarification in https://crbug.com/chromedriver/2513#c7 .
Regarding ChromeDriver 2.41 inhttps://crbug.com/chromedriver/2513#c5 : Does this mean that with ChromeDriver 2.41 "new ChromeDriver()" (without specifying any options) would just work out-of-the-box when a group policy for the user data dir is defined? Or will there be a new option for the DevTools part?
Regarding ChromeDriver 2.41 in
jo...@chromium.org <jo...@chromium.org> #10
With ChromeDriver 2.41, you will still need explicit action to work around a group policy for the user data dir, but there will be a new option, to explicitly select a port for DevTools to use. E.g.,
ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.addArguments("remote-debugging-port=10000");
ChromeDriver driver = new ChromeDriver(chromeOptions);
We are still considering how to make "new ChromeDriver()" works without need to specify any options, but that will be for a later release.
ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.addArguments("remote-debugging-port=10000");
ChromeDriver driver = new ChromeDriver(chromeOptions);
We are still considering how to make "new ChromeDriver()" works without need to specify any options, but that will be for a later release.
ph...@gmail.com <ph...@gmail.com> #11
@johnchen
> When there is a group policy overriding user data dir, it's not possible to run multiple instances of Chrome, since Chrome is not designed to share the same user data dir among multiple instances.
When the registry key is not set chromedriver by default does not use the user data dir of the users default profile but a temporary directory for each started chromedriver instance. Shouldn't be the behavior be just the same even when the registry key is set?
> When there is a group policy overriding user data dir, it's not possible to run multiple instances of Chrome, since Chrome is not designed to share the same user data dir among multiple instances.
When the registry key is not set chromedriver by default does not use the user data dir of the users default profile but a temporary directory for each started chromedriver instance. Shouldn't be the behavior be just the same even when the registry key is set?
cr...@chromium.org <cr...@chromium.org> #12
+Scott, is it possible that we could have some way to start Chrome at a specific user-data-dir when the registry key HKEY_CURRENT_USER\Software\Policies\Google\Chrome\UserDataDir is set, or would that be some kind of security problem or breach of enterprise policy?
jo...@hotmail.com <jo...@hotmail.com> #13
fl...@microsoft.com <fl...@microsoft.com> #14
[Empty comment from Monorail migration]
ne...@chromium.org <ne...@chromium.org> #15
We have implemented communication over pipes between ChromeDriver and Chrome.
If you provide '--remote-debugging-pipe' argument instead of '--remote-debugging-port' to Chrome then DevToolsActivePort will no longer be used.
With time pipes will become the default communication mode.
Linked tohttps://bugs.chromium.org/p/chromedriver/issues/detail?id=3480
If you provide '--remote-debugging-pipe' argument instead of '--remote-debugging-port' to Chrome then DevToolsActivePort will no longer be used.
With time pipes will become the default communication mode.
Linked to
ne...@chromium.org <ne...@chromium.org> #16
Resolving the issue as fixed as there is a workaround.
Description
Steps to reproduce:
1) Specify a valid directory via the setting the registry value HKEY_CURRENT_USER\Software\Policies\Google\Chrome\UserDataDir
2) Run the following Java code:
WebDriver driver = new ChromeDriver();
This opens Chrome and then fails after about one minute with the following error:
org.openqa.selenium.WebDriverException: unknown error: DevToolsActivePort file doesn't exist
(Driver info: chromedriver=2.40.565498 (ea082db3280dd6843ebfb08a625e3eb905c4f5ab),platform=Windows NT 10.0.16299 x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 60.12 seconds
Build info: version: '3.13.0', revision: '2f0d292', time: '2018-06-25T15:32:14.902Z'
System info: host: '.....', ip: '.....',
Driver info: driver.version: ChromeDriver
Notes:
* ChromeDriver starts Chrome with the command line arg --user-data-dir=C:\Users\<username>\AppData\Local\Temp\scoped_dir<some_number>. A few files are created in this directory. However, the vast majority of the user data dir files (including the DevToolsActivePort file) are created in the directory that is specified by the registry value.
* I observed a different (possibly related?) issue in chromedriver 2.38: Calling "new ChromeDriver()" two times in a row launches one Chrome instance with two tabs. The first ChromeDriver constructor succeeds and the second one fails after about one minute with the following exception:
org.openqa.selenium.WebDriverException: unknown error: Chrome failed to start: crashed
(Driver info: chromedriver=2.38.552522 (437e6fbedfa8762dec75e2c5b3ddb86763dc9dcb),platform=Windows NT 10.0.16299 x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 61.65 seconds
Build info: version: '3.13.0', revision: '2f0d292', time: '2018-06-25T15:32:14.902Z'
System info: host: '.....', ip: '.....',
Driver info: driver.version: ChromeDriver