New issue
Advanced search Search tips

Issue 863581 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

ChromeDriver doesn't handle reuse of active user-data-dir helpfully

Project Member Reported by crouleau@chromium.org, Jul 13

Issue description

If you start two instances of chrome against the same user-data-dir, then the second instance will simply print "Created new window in existing browser session." and exit. 

There is a race condition here where if two ChromeDriver instances (instance A and instance B) are started against the same user-data-dir then the following could happen:

 - instance A checks for a already existing DevToolsActivePort file and deletes it if it exists.
 - instance B checks for a already existing DevToolsActivePort file and deletes it if it exists.
 - instance A starts Chrome at the given user-data-dir. Chrome writes the DevToolsActivePort file to that directory. instance A connects to devtools at the port given by the DevToolsActivePort file.
 - instance B starts Chrome at the given user-data-dir, but Chrome simply prints "Created new window in existing browser session." and exits. At this point, instance B should exit saying that it failed to start Chrome, but instead it continues forward, reads the DevToolsActivePort file, and connects to DevTools about that given port.

Now we have two ChromeDriver instances connecting to the same Chrome!

Note that there are two reasons that this "bug" isn't very important:

1. User should not give us the same user-data-dir for two different Chrome runs. There's no way for us to handle this scenario anyway.

2. Usually the order of operations above is not the way that this works. Usually instance B deletes the DevToolsActivePort file created by instance A and then instance B times out waiting for a new DevToolsActivePort file to be created.

3. Usually no user-data-dir is provided by the user anyway, and ChromeDriver uses CreateUniqueTempDir https://cs.chromium.org/chromium/src/base/files/scoped_temp_dir.h?g=0&l=36 to create a new randomly-named temporary directory, so no collision or race condition is possible.


The solution to this problem is for ChromeDriver to handle the "Created new window in existing browser session." case and throw a helpful error for it. I'm not really sure why the current code doesn't handle this case already, so we will need to look into it.


 
Owner: johnchen@chromium.org
Owner: buldina@chromium.org
Tatiana: Could you please take a look at this issue?

This issue can be repro'ed with the following Python script:

from selenium import webdriver
opt = webdriver.ChromeOptions()
opt.add_argument('user-data-dir=foo')
driver = webdriver.Chrome(options=opt)

Running this script for the first time should succeed, but running it a second time from the same location (while keeping open the Chrome window created by the first run) should result in an exception with an error that Chrome has crashed. We want a better error message.

Please modify the main loop inside LaunchDesktopChrome function in https://cs.chromium.org/chromium/src/chrome/test/chromedriver/chrome_launcher.cc, where ChromeDriver waits for Chrome to become active. When the code finds out that Chrome is no longer running, it should check the exit_code to see if it equals to chrome::RESULT_CODE_NORMAL_EXIT_PROCESS_NOTIFIED. If it does, the code should return an error that indicates the user data directory is already in use, and advise the user to either specify a unique value for --user-data-dir argument, or don't use --user-data-dir.

On Windows, exit_code can be directly compared against chrome::RESULT_CODE_NORMAL_EXIT_PROCESS_NOTIFIED. On Posix systems (Linux & Mac), it's necessary to use WEXITSTATUS(exit_code) instead. Please test the code on both Linux and Windows to make sure it works properly.

Sign in to add a comment