Description
Background
I am in charge of maintenance of a Java-based test automation framework that uses Selenium (via its Java bindings) for the browser-driven web testing feature area. It was created prior to the existence of the Selenium Manager, so we used the WebDriverManager (WDM) library to automatically download & setup the appropriate ChromeDriver for a static Chrome browser installation on a test VM (which is periodically allowed to update).
Now that Selenium offers this functionality via its bundled-in Manager companion application, I would like to use Selenium solely for browser & webdriver management and thus eliminate WDM as a dependency (I know I'm late to the party, but it wasn't broken so 🤷♂️), plus to reap the additional bonus of fully-automated browser management.
Initial testing was promising, as the Selenium Manager's functionality seamlessly and silently filled in the gaps left by WDM, even when I uninstalled the existing browser installation. However, there is one last use case that I can't for the life of me get to work: one of the applications under test is an Electron-based app, which we currently use WDM to launch without (much) issue. The only extra steps are that we need to supply it a path to the Electron binary and specify which version of ChromeDriver to use (each version of Electron uses a particular version of Chromium under the hood, so we were able to determine the appropriate version by that). WDM will then download the version of ChromeDriver we told it to use and Selenium launches it successfully. For whatever reason, the Electron app is very particular about which version of ChromeDriver is used and will crash immediately without much trace if the vibe/version isn't right.
The Java bindings do not expose the ability to set a ChromeDriver version like they do a browser version, but I eventually figured out it could be done by setting the SE_CHROMEDRIVER_VERSION system property in the consuming code, which gets passed to the Manager binary as an environment variable by the Java bindings. Unfortunately though, there is logic in the Manager's Rust code where it will only actually pay attention to the major version of the ChromeDriver that I specified and just get the whatever the last element matching the major version is from the GOOD_VERSIONS_ENDPOINT URL. See the request_good_driver_version_from_online() method in chrome.rs, specifically here and here). Interestingly, it still the names the path on disk that it saves the ChromeDriver to based on the specified version rather than the actual version it gets. I've looked high and low for a way to force it to use an exact match rather than "latest matching version" match, but at the end of the day this appears to be the only place where it downloads a non-latest version of ChromeDriver and there's no way around the "get latest major version" logic, so I'm concluding it's impossible in the current state.
TL;DR: I need the Selenium Manager to download the exact version of ChromeDriver that I tell it but at best it will only get the latest patch of the major version that I specified.
Acceptance Criteria
- There is some way to tell the Manager not to use the "get latest major version" logic for downloading ChromeDriver and only perform an exact version match. I assume that logic exists for a good reason for most cases, but there's at least one where it breaks functionality. This could be either by adding a new environment variable to check for like
SE_USE_EXACT_DRIVER_VERSION, or maybe just assume that if a full version with .s is specified (like "144.0.7500.0") then don't assume you know better what the caller wants. I would prefer the latter as it's simpler and less misleading.
- It would also be nice to add a
setDriverVersion method to either ChromiumOptions or AbstractDriverOptions (in the Java bindings) to make it more clear that it's possible to configure that (rather than making people look for the not-obvious system property/environment variable method I eventually found).
I can make these changes myself, I just wanted to first make sure there's agreement on the need for the change.
Have you considered any alternatives or workarounds?
Yes, I tried pretty much everything. There is no workaround that I can find.
Description
Background
I am in charge of maintenance of a Java-based test automation framework that uses Selenium (via its Java bindings) for the browser-driven web testing feature area. It was created prior to the existence of the Selenium Manager, so we used the WebDriverManager (WDM) library to automatically download & setup the appropriate ChromeDriver for a static Chrome browser installation on a test VM (which is periodically allowed to update).
Now that Selenium offers this functionality via its bundled-in Manager companion application, I would like to use Selenium solely for browser & webdriver management and thus eliminate WDM as a dependency (I know I'm late to the party, but it wasn't broken so 🤷♂️), plus to reap the additional bonus of fully-automated browser management.
Initial testing was promising, as the Selenium Manager's functionality seamlessly and silently filled in the gaps left by WDM, even when I uninstalled the existing browser installation. However, there is one last use case that I can't for the life of me get to work: one of the applications under test is an Electron-based app, which we currently use WDM to launch without (much) issue. The only extra steps are that we need to supply it a path to the Electron binary and specify which version of ChromeDriver to use (each version of Electron uses a particular version of Chromium under the hood, so we were able to determine the appropriate version by that). WDM will then download the version of ChromeDriver we told it to use and Selenium launches it successfully. For whatever reason, the Electron app is very particular about which version of ChromeDriver is used and will crash immediately without much trace if the vibe/version isn't right.
The Java bindings do not expose the ability to set a ChromeDriver version like they do a browser version, but I eventually figured out it could be done by setting the
SE_CHROMEDRIVER_VERSIONsystem property in the consuming code, which gets passed to the Manager binary as an environment variable by the Java bindings. Unfortunately though, there is logic in the Manager's Rust code where it will only actually pay attention to the major version of the ChromeDriver that I specified and just get the whatever the last element matching the major version is from the GOOD_VERSIONS_ENDPOINT URL. See therequest_good_driver_version_from_online()method inchrome.rs, specifically here and here). Interestingly, it still the names the path on disk that it saves the ChromeDriver to based on the specified version rather than the actual version it gets. I've looked high and low for a way to force it to use an exact match rather than "latest matching version" match, but at the end of the day this appears to be the only place where it downloads a non-latest version of ChromeDriver and there's no way around the "get latest major version" logic, so I'm concluding it's impossible in the current state.TL;DR: I need the Selenium Manager to download the exact version of ChromeDriver that I tell it but at best it will only get the latest patch of the major version that I specified.
Acceptance Criteria
SE_USE_EXACT_DRIVER_VERSION, or maybe just assume that if a full version with.s is specified (like "144.0.7500.0") then don't assume you know better what the caller wants. I would prefer the latter as it's simpler and less misleading.setDriverVersionmethod to eitherChromiumOptionsorAbstractDriverOptions(in the Java bindings) to make it more clear that it's possible to configure that (rather than making people look for the not-obvious system property/environment variable method I eventually found).I can make these changes myself, I just wanted to first make sure there's agreement on the need for the change.
Have you considered any alternatives or workarounds?
Yes, I tried pretty much everything. There is no workaround that I can find.