From 115 onwards, point to https://googlechromelabs.github.io/chrome-for-testing/

[nekennedy]

Based on this thread: https://groups.google.com/g/chromedriver-users/c/clpipqvOGjE/m/kjNfVizXAgAJ The location for the chromedrivers is changing to https://googlechromelabs.github.io/chrome-for-testing/

I have a user who got put on the "Early Stable Release" track so hit this today instead of tomorrow, but I think everything breaks tomorrow.

[shawnCaza]

There's some more comments here about the changes.

Two big things that standout to me is every version will have a corresponding driver. Maybe that means we can cut out some of the logic around getting the major release number.

The end point listing releases in now in JSON format vs the old XML file autoinstaller currently looks at.

[shawnCaza]

I managed to make changes that downloads the driver from the new end point. It looks right to me, but I can't get selenium to recognize the driver.

The code changes I made are here if anyone would like to find improvements.

[shawnCaza]

Turns out chrome not recognizing the driver is a known bug facing Mac users right now. from the chrome driver group:

We’re aware of an issue where ChromeDriver 115 on macOS doesn’t find the regular Google Chrome browser binary at its default location. The relevant crbug is https://bugs.chromium.org/p/chromium/issues/detail?id=1466427. We’ve already identified the issue and submitted a fix for M117, and are currently working on back-merging the fix to M115 and M116 as well. Until this process is complete, you can use any of the workarounds we’ve posted on GitHub.

[GQAssurance]

It looks like 2 of us simultaneously came up with different solutions to support 115+

@shawnCaza has a PR with efficient changes that will not support any chrome lower than 115 @GQAssurance has a backwards compatible PR that keeps the old complexity

It might be worthwhile for @yeongbin-jo to express a preference

[shawnCaza]

Thanks @GQAssurance your PR looks very good. I think we should merge yours as is since the current version is broken for new versions of chrome. I could test on windows but it will take me few days.

The code is getting a little more complex with accommodations for a variety of version ranges, but I don't think that should stop us from supporting older browsers. At most I'd think about breaking some of the version logic into separate functions for readability.

A future consideration, if we are now downloading minor versions of the driver, that could multiply the number of drivers stored. I wonder if it's worth thinking about a option to clean up older versions, or preserving only a specified number of versions.

[GQAssurance]

A future consideration, if we are now downloading minor versions of the driver, that could multiply the number of drivers stored.

@shawnCaza My reading of the original code is that download_chromedriver will overwrite minor version updates within the same major-version directory.

This PR does not change the "Where do we store our shiny new chromedriver file?" logic, so I'd expect that overwriting to be retained.

[soorower]

This will work for 115.0.5790.102 and upwards... https://pypi.org/project/chromedriver-auto/1.0.11/

[yeongbin-jo]

Thanks for the PR @GQAssurance @shawnCaza I have merged your changes and updated the package to version 0.6.0.

[nekennedy]

For those coming to this issue later, I ended up upgrading to Selenium 4 and relying on the new 'selenium manager' to automatically download chromedrivers instead of the code in this repo.

This library is great if you need more control than Selenium Manager offers, or don't want to update to the newest version of Selenium!