[rust] Use CfT endpoints to discover chromedriver 115+

[bonigarcia]

Description

The Chrome team is doing recently relevant changes related to Chrome for Testing (CfT). In particular, the metadata for discovering chromedriver as of version 115 is now different. This PR makes the required changes in the Rust-side of Selenium Manager to support chromedriver 115+ downloads using the new CfT endpoints.

Motivation and Context

This change is required to be shipped with the bindings at least when Chrome 115 is released as stable (according to the Chrome roadmap, by July 12, 2023).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[diemol]

Thanks, @bonigarcia!

If I understand correctly, we try first the new endpoint, and if no ChromDriver is found there, we go back to LATEST_RELEASE, right?

And then, eventually, when Chrome 115 is released, the information for ChromeDriver will be present in the Chrome for Testing endpoints. I hope I got that one right.

[bonigarcia]

Yes, something like that. Let me explain a bit.

First, we try to discover the browser (Chrome) version (by running some command(s) in the shell). Using the found version, there are different cases for discovering the driver (chromedriver) version:

• Chrome < 115: In this case, the old metadata is still used (e.g., https://chromedriver.storage.googleapis.com/LATEST_RELEASE_114).

• Chrome >= 115: In this case, one of the new CfT endpoints is used (https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json).

• Chrome version is unknown: Another CfT endpoint is used to get the latest stable version (https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions-with-downloads.json). Here, there is a corner since the current stable version (i.e., 114) is not published in the new endpoint. Therefore, the old metadata (https://chromedriver.storage.googleapis.com/LATEST_RELEASE) is used if the chromedriver version is unavailable (which only happens currently but not in the future).

[diemol]

Thanks!

[NathanSmeltzer]

If anyone is looking for a temporary fix until the next release, you can specify an older version in ChromeDriverManager:
ChromeDriverManager(version="114.0.5735.90")

[diemol]

ChromeDriverManager is not part of this project, that might be misleading for someone looking for a fix.

[titusfortner]

@occamssafetyrazor you are mixing up the Selenium Manager which is in the Selenium code and the WebDriver Manager project, which is not.

It is confusing because @bonigarcia writes both. :)
Selenium has the fix for it, but we need to do another release, and we have a couple things holding it up, but hope to have something out shortly.

[Akkasim46]

I still see the issue with 115 chrome version.
org.openqa.selenium.SessionNotCreatedException: Could not start a new session. Response code 500. Message: unknown error: cannot find Chrome binary

[bonigarcia]

@Akkasim46 That is due to a problem in chromedriver 115 in macOS (see GoogleChromeLabs/chrome-for-testing#30).

As a workaround in Selenium (and macOS), you can specify the Chrome binary path as follows (or its equivalent in other binding language):

ChromeOptions options = new ChromeOptions();
options.setBinary("/Applications/Google Chrome.app/Contents/MacOS/Google Chrome");
WebDriver driver = new ChromeDriver(options);

[Akkasim46]

Thanks a lot @bonigarcia
It works!
will there be a permanent solution with a new webdrivermanager release?

[bonigarcia]

The workaround will not be needed when the chromedriver team ships a new version of chromedriver 115 with the fix. Selenium or WebDriverManager does not cause it.