Selenium – manager

Blog: Novelties in Selenium Manager 0.4.15

Mon, 13 Nov 2023 00:00:00 +0000

Support for Firefox ESR

Selenium Manager 0.4.15 includes support for Firefox Extended Support Release (ESR). This way, Firefox ESR can be automatically managed with Selenium using the label esr in the browser version. Bindings languages set this browser version (like other accepted labels for browser versions, such as stable, beta, dev, canary, and nightly) using a browser option called browserVersion.

Support for Edge WebView2

Selenium Manager 0.4.15 allows automated driver management for Microsoft Edge WebView2. WebView2 is a component that enables embedding web technologies (HTML, CSS, and JavaScript) in native apps, using Microsoft Edge as the rendering engine to display web content. At the time of this writing, WebView2 is available in Windows.

This way, Selenium Manager allows detecting WebView2 in Windows machines and resolving the proper msedgedriver binary for it. Internally, Selenium Manager uses the browser name webview2 to handle WebView2, detecting its version based on registry queries. In the bindings, WebView2 is enabled through a browser option called useWebView.

Support for mirror repositories

Selenium Manager 0.4.15 includes a couple of new arguments in Selenium Manager for specifying custom URLs for drivers and browsers (instead of the default ones, such as chromedriver, Chrome for Testing, etc.). These arguments are:

--driver-mirror-url: Mirror URL for driver repositories.
--browser-mirror-url: Mirror URL for browser repositories.

As usual, these values can be configured using the config file or environment variable (e.g., SE_DRIVER_MIRROR_URL or SE_BROWSER_MIRROR_URL). Moreover, there are browser and driver-specific configuration keys, i.e. chrome-mirror-url, firefox-mirror-url, edge-mirror-url, etc. (in the configuration file), and SE_CHROME_MIRROR_URL, SE_FIREFOX_MIRROR_URL, SE_EDGE_MIRROR_URL, etc. (as environment variables).

Here is an example of this feature calling Selenium Manager from the shell:

./selenium-manager --debug --browser chrome --browser-version 100 --avoid-browser-download --driver-mirror-url=https://registry.npmmirror.com/-/binary/chromedriver/
DEBUG chromedriver not found in PATH
DEBUG chrome detected at C:\Program Files\Google\Chrome\Application\chrome.exe
DEBUG Running command: wmic datafile where name='C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe' get Version /value
DEBUG Output: "\r\r\n\r\r\nVersion=117.0.5938.150\r\r\n\r\r\n\r\r\n\r"
DEBUG Detected browser: chrome 117.0.5938.150
DEBUG Discovered chrome version (117) different to specified browser version (100)
DEBUG Required driver: chromedriver 100.0.4896.60
DEBUG Downloading chromedriver 100.0.4896.60 from https://registry.npmmirror.com/-/binary/chromedriver/100.0.4896.60/chromedriver_win32.zip
INFO Driver path: C:\Users\boni\.cache\selenium\chromedriver\win64\100.0.4896.60\chromedriver.exe
INFO Browser path: C:\Program Files\Google\Chrome\Application\chrome.exe

Debug release

To troubleshoot Selenium Manager in complex error cases, it is interesting to capture the backtrace. But to do that, the Selenium Manager binaries must be created with the debug symbols. Since the resulting binaries with debug symbols are much larger than the default release artifacts, we generate them on demand using a custom workflow in GitHub Actions. This way, we have included a checkbox in the workflow for triggering the Selenium Manager build. When this checkbox is enabled when building Selenium Manager, the debug symbols will be added to the resulting binaries (for Windows, Linux, and macOS). All in all, these binaries will be used on demand to troubleshoot complicated problems.

Selenium Manager in cache (only for Java bindings)

As of version 4.15.0 of the Selenium Java bindings, the Selenium Manager binary is extracted and copied to the cache folder. For instance, the Selenium Manager binary shipped with Selenium 4.15.0 is stored in the folder ~/.cache/selenium/manager/0.4.15). This feature will allow direct manipulation of Selenium Manager as a CLI tool, for instance, for troubleshooting. This feature is only available for Java bindings since Java is the only language that does not have direct access to the Selenium Manager binaries (since they are released compressed into the JAR files of the selenium-java artifacts).

Next steps

Look at Selenium Manager documentation for a detailed description of its features. Also, you can trace the status of the development activities in the Selenium Manager project dashboard.

Blog: Status of Selenium Manager in October 2023

Tue, 17 Oct 2023 00:00:00 +0000

Selenium Manager continues its development plan. As usual, in the latest releases, i.e., 0.4.13 and 0.4.14 (shipped with Selenium 4.13 and 4.14, respectively), we have fixed the problems reported so far. In these releases, the issues were related to the extraction of the Firefox binary from the self-extracting archive (SFX) in Windows and the advanced configuration through the configuration file (se-config.toml) and environment variables (e.g., SE_BROWSER). Moreover, these recent releases include new features, as explained below.

Search for the best driver possible in the cache

By default, Selenium Manager needs to request online endpoints (such as Chrome for Testing JSON API or Firefox product-details JSON API to discover, download, and maintain the proper drivers and browsers that Selenium requires. The downloaded artifacts are stored in the cache (by default, ~/.cache/selenium) and reused from there.

To make the driver resolution procedure more robust, as of version 0.4.13, Selenium Manager includes a new feature for locating the drivers in the cache when some error happens. This way, when a network request (or other function) fails in Selenium Manager, it tries to locate the driver in the cache. This characteristic aims to provide a best-effort solution for creating a Selenium session properly, which is the final objective of Selenium Manager. Also, this feature will help to provide a better experience for locating drivers for Selenium Grid.

Locating Selenium Manager binary with an environment variable

The next feature related to Selenium Manager 0.4.13 has been implemented in the Selenium bindings (i.e., Java, JavaScript, Python, .Net, and Ruby). As of Selenium 4.13.0, the Selenium bindings allow locating the Selenium Manager binary using an environment variable called SE_MANAGER_PATH. This way, if this variable is set, the bindings will use its value as the Selenium Manager path in the local filesystem. This feature will allow users to provide a custom compilation of Selenium Manager, for instance, if the default binaries (compiled for Windows, Linux, and macOS) are incompatible with a given system (e.g., ARM64 in Linux).

Automated Edge management

Selenium Manager 0.4.14 includes automated Edge management. This browser is the last we have in mind for this feature, after Chrome and Firefox.

This feature has been implemented in the same way that Chrome and Firefox for macOS and Linux. In other words, Selenium Manager allows to automatically manage (i.e., discover, downloads, and cache) the latest Edge versions (i.e., stable, beta, dev, canary) and old versions (e.g., 115, 116, etc.). The downloaded binaries, as usual, are stored in the Selenium cache. The following output commands showcase this feature in macOS (first snipped) and Linux (second snippet):

./selenium-manager --browser edge --debug --force-browser-download
DEBUG msedgedriver not found in PATH
DEBUG Checking edge releases on https://edgeupdates.microsoft.com/api/products
DEBUG Required browser: edge 117.0.2045.40
DEBUG Downloading edge 117.0.2045.40 from https://msedge.sf.dl.delivery.mp.microsoft.com/filestreamingservice/files/6e65d9ef-0bb9-4636-8d9e-2b1b9d16149d/MicrosoftEdge-117.0.2045.40.pkg
DEBUG edge 117.0.2045.40 has been downloaded at /Users/boni/.cache/selenium/edge/mac64/117.0.2045.40/Microsoft Edge.app/Contents/MacOS/Microsoft Edge
DEBUG Reading msedgedriver version from https://msedgedriver.azureedge.net/LATEST_RELEASE_117_MACOS
DEBUG Required driver: msedgedriver 117.0.2045.40
DEBUG Downloading msedgedriver 117.0.2045.40 from https://msedgedriver.azureedge.net/117.0.2045.40/edgedriver_mac64.zip
INFO Driver path: /Users/boni/.cache/selenium/msedgedriver/mac64/117.0.2045.40/msedgedriver
INFO Browser path: /Users/boni/.cache/selenium/edge/mac64/117.0.2045.40/Microsoft Edge.app/Contents/MacOS/Microsoft Edge

./selenium-manager --browser edge --debug --browser-version beta
DEBUG msedgedriver not found in PATH
DEBUG edge not found in PATH
DEBUG edge beta not found in the system
DEBUG Checking edge releases on https://edgeupdates.microsoft.com/api/products
DEBUG Required browser: edge 118.0.2088.11
DEBUG Downloading edge 118.0.2088.11 from https://packages.microsoft.com/repos/edge/pool/main/m/microsoft-edge-beta/microsoft-edge-beta_118.0.2088.11-1_amd64.deb
DEBUG edge 118.0.2088.11 has been downloaded at /home/user/.cache/selenium/edge/linux64/118.0.2088.11/msedge
DEBUG Reading msedgedriver version from https://msedgedriver.azureedge.net/LATEST_RELEASE_118_LINUX
DEBUG Required driver: msedgedriver 118.0.2088.11
DEBUG Downloading msedgedriver 118.0.2088.11 from https://msedgedriver.azureedge.net/118.0.2088.11/edgedriver_linux64.zip
INFO Driver path: /home/user/.cache/selenium/msedgedriver/linux64/118.0.2088.11/msedgedriver
INFO Browser path: /home/user/.cache/selenium/edge/linux64/118.0.2088.11/msedge

Nevertheless, this feature cannot be implemented similarly for Windows. The reason is that the Edge installer for Windows is distributed as a Microsoft Installer (MSI) file, designed to be executed with administrator rights. We tried to extract the Edge binaries from that MSI file. Still, it seems not possible (see Stack Overflow post that summarized the problem). All in all, the only solution we found is to install Edge in Windows using the MSI installer, and so, administrator grants are required.

This way, when Edge is attempted to be installed with Selenium Manager in Windows with a non-administrator session, a warning message will be displayed as follows:

./selenium-manager --debug --browser edge --browser-version beta
DEBUG msedgedriver not found in PATH
DEBUG edge not found in PATH
DEBUG edge beta not found in the system
WARN There was an error managing edge (edge can only be installed in Windows with administrator permissions); using driver found in the cache
INFO Driver path: C:\Users\boni\.cache\selenium\msedgedriver\win64\118.0.2088.17\msedgedriver.exe

But when Selenium Manager is executed with administrator grants in Windows, it will be able to automatically discover, download, and install Edge (stable, beta, dev, canary, and older versions):

./selenium-manager --debug --browser edge --browser-version beta
DEBUG msedgedriver not found in PATH
DEBUG edge not found in PATH
DEBUG edge beta not found in the system
DEBUG Checking edge releases on https://edgeupdates.microsoft.com/api/products
DEBUG Required browser: edge 118.0.2088.17
DEBUG Downloading edge 118.0.2088.17 from https://msedge.sf.dl.delivery.mp.microsoft.com/filestreamingservice/files/7adec542-f34c-4dea-8e2a-f8c6fab4d2f3/MicrosoftEdgeBetaEnterpriseX64.msi
DEBUG Installing MicrosoftEdgeBetaEnterpriseX64.msi
DEBUG edge 118.0.2088.17 is available at C:\Program Files (x86)\Microsoft\Edge Beta\Application\msedge.exe
DEBUG Required driver: msedgedriver 118.0.2088.17
DEBUG msedgedriver 118.0.2088.17 already in the cache
INFO Driver path: C:\Users\boni\.cache\selenium\msedgedriver\win64\118.0.2088.17\msedgedriver.exe
INFO Browser path: C:\Program Files (x86)\Microsoft\Edge Beta\Application\msedge.exe

Chromium support

Chromium is released as portable binaries, distributed as zip files for Windows, Linux, and macOS (see Chromium download page). Nevertheless, there is a case in which Chromium is actually installed in the system. This happens in Linux systems when installing Chromium through package managers like atp or snap, for instance, as follows:

sudo snap install chromium

Therefore, as of 0.4.14, Selenium Manager looks for the Chromium binaries in the PATH when Chrome is not discovered. The following snippet showcases how this feature works in a Linux machine in which Chrome is not available, but Chromium has been installed through snap:

./selenium-manager --browser chrome --debug
DEBUG chromedriver not found in PATH
DEBUG Found chromium in PATH: /snap/bin/chromium
DEBUG Running command: /snap/bin/chromium --version
DEBUG Output: "Chromium 117.0.5938.149 snap"
DEBUG Detected browser: chrome 117.0.5938.149
DEBUG Required driver: chromedriver 117.0.5938.149
DEBUG chromedriver 117.0.5938.149 already in the cache
INFO Driver path: /home/user/.cache/selenium/chromedriver/linux64/117.0.5938.149/chromedriver
INFO Browser path: /snap/bin/chromium

Next steps

We are close to implementing all the features initially planned for Selenium Manager. You can trace the status of the development activities in the Selenium Manager project dashboard.

Blog: What's new in Selenium Manager 0.4.12, shipped with Selenium 4.12.0

Mon, 28 Aug 2023 00:00:00 +0000

A new release of Selenium Manager is out. For this release, we made a relevant decision concerning the Selenium Manager versioning format. From now on, Selenium Manager will follow the same version as Selenium. Nevertheless, since Selenium Manager is still in beta, its major version is 0. Thus, Selenium 4.12.0 is shipped with Selenium Manager 0.4.12.

First, we made a substantial effort to stabilize the already available features on Selenium Manager. This way, the version includes several bug-fixing related to automated driver management or caching. You can find the details of the changes implemented in Selenium Manager 0.4.12 in the (newly created) changelog file.

Besides, for this release, we made a significant update to the documentation page of Selenium Manager. This page contains all the fine-grained information related to automated driver and browser management, configuration, etc. Also, it has several TL;DR summarizing the main ideas for the eager reader.

Automated Firefox management

After shipping automated browser management based on Chrome for Testing on the previous release, Selenium Manager 0.4.12 continues the job by providing automated Firefox management. This way, Selenium Manager 0.4.12 allows us to manage the different Firefox releases (for Windows, Linux, and macOS), making them seamlessly available for Selenium.

The procedure is the same as with Chrome. When Firefox is unavailable in the machine running Selenium, it is automatically discovered, downloaded, and cached by Selenium. If no version is specified, the latest stable Firefox release is managed by Selenium Manager. Besides, the bindings can use a browser option called browserVersion to specify a particular Firefox release (e.g., 114, 115, etc.). Finally, the label stable allows us to manage the current stable Firefox release explicitly, and the labels beta, dev, and nightly as used for unstable Firefox releases.

This feature is possible thanks to the remarkable work of the Firefox team by maintaining current and old releases in their public repository. Moreover, the Firefox version discovery in Selenium Manager is made thanks to the availability of the product-details JSON API, also maintained by the Firefox team.

Improved configuration

Custom setup is sometimes necessary for browser automation. For that reason, Selenium Manager already provides different features for rich configuration. Selenium Manager 0.4.12 extends this feature by delivering a new configuration argument called --cache-path. This argument allows changing the path of the local folder used to store downloaded assets (drivers and browsers) by Selenium Manager (by default, ~/.cache/selenium). As usual, this argument can also be changed by including an entry in the configuration file or using an environment variable (SE_CACHE_PATH). Regarding the former, the name of the configuration file has been renamed to se-config.toml in Selenium Manager 0.4.12. As usual, if you use this configuration file, it must be placed in the root of the cache folder.

Other changes

A minor change in Selenium Manager 0.4.12 is related to the metadata file, now called se-metadata.json. As usual, this file is stored in the root of the cache folder. This file contains versions discovered by Selenium Manager making network requests and the time-to-live (TTL) in which they are valid. Since the TTL for browsers and drivers is now the same concept, Selenium Manager unifies these two configuration elements (previously, browser_ttl and driver_ttl) in a single one called ttl (with a default value of 3600 seconds, i.e., 1 hour). For further details, visit the Selenium Manager page about caching.

Last but not least, the Selenium Manager binary compiled for macOS is universal, in the sense that it can be executed both in x64 and arm64 architectures out of the box. Previously, the binary was compiled for x64, and so, Rosetta should be available in arm64 macOS machines (i.e., M1 or M2). With the new Selenium Manager macOS binary, Rosetta is no longer mandatory.

Next steps

The next release of Selenium Manager will continue delivering automated browser management, this time for Edge, and other features. As usual, you can trace the work in progress in the Selenium Manager project dashboard.

Blog: What's new in Selenium Manager with Selenium 4.11.0

Mon, 31 Jul 2023 00:00:00 +0000

As of version 4.6.0, all releases of Selenium (Java, JavaScript, Python, Ruby, and .Net) are shipped with Selenium Manager. Selenium Manager is a binary tool (implemented in Rust) that provides automated driver management for Selenium. Selenium Manager is still in beta, although it is becoming a relevant component of Selenium.

So far, the main feature of Selenium Manager is called automated driver management. I use the term management for this feature (and not just download) since this process is broader and implies different steps:

Browser version discovery. Selenium Manager discovers the browser version (e.g., Chrome, Firefox, Edge) installed in the machine that executes Selenium. For this step, shell commands are used (e.g., google-chrome --version).
Driver version discovery. With the discovered browser version, the proper driver version is resolved. For this step, the online metadata maintained by the browser vendors (e.g., chromedriver, geckodriver, or msedgedriver) are used.
Driver download. With the resolved driver version, the driver URL is obtained; with that URL, the driver artifact is downloaded, uncompressed, and stored locally.
Driver cache. Uncompressed driver binaries are stored in a local cache folder (~/.cache/selenium). The next time the same driver is required, if the driver is already in the cache, it will be used from there.

Drivers on the PATH

Driver management through Selenium Manager is opt-in for the Selenium bindings. Thus, users can continue managing their drivers manually (putting the driver in the PATH or using system properties) or rely on a third-party manager to do it automatically. Selenium Manager only operates as a fallback: if no driver is provided, Selenium Manager will come to the rescue. Nevertheless, Selenium Manager also helps users to identify potential problems with the drivers on the PATH.

Let’s consider an example. Imagine you manually manage your chromedriver for your Selenium tests. When you carry out this management, the stable version of Chrome is 113, so you download chromedriver 113 and put it in your PATH. Your Selenium tests execute. Everything is fine. But the problem here is that Chrome is evergreen. This name refers to Chrome’s ability to upgrade automatically and silently to the next stable version when available. This feature is excellent for end-users but potentially dangerous for automated testing. Let’s go back to the example to discover it. Your local Chrome will eventually update to version 115. And that moment, your Selenium tests will be broken due to the incompatibility of the manually managed driver (113) and your Chrome (115). That day, your test dashboard will be red due to the following error message: “session not created: This version of ChromeDriver only supports Chrome version 113”.

This problem is the primary reason for the existence of the so-called driver managers. And as of Selenium 4.11, Selenium Manager helps to understand potential issues related to the drivers in the PATH. When an incompatible driver release is found in the PATH, a warning message like the following is displayed to the user:

WARN The chromedriver version (113.0.5672.63) detected in PATH at C:\my-drivers\chromedriver.exe might not be compatible with the detected chrome version (115.0.5790.110); currently, chromedriver 115.0.5790.102 is recommended for chrome 115.*, so it is advised to delete the driver in PATH and retry

Entering Chrome for Testing (CfT)

The Chrome team started a very relevant initiative for the testing community in 2023: Chrome for Testing (CfT). CfT is a reduced release of Chrome primarily addressed to the testing use case.

One of the key differences between a regular Chrome release and CfT is that Chrome is evergreen, but CfT is not. This way, CfT allows pined browsers for testing. CfT releases are portable binaries (for Windows, Linux, and macOS) for different versions, including the stable, beta, dev, and canary channels. These releases can be programmatically discovered using the CfT JSON endpoints.

As of version 114, the chromedriver team has stopped publishing the chromedriver releases and metadata using their traditional chromedriver download repository. This way, and as of version 115, chromedriver releases can only be discovered programmatically using the abovementioned CfT JSON endpoints.

This change has been very relevant for the so-called driver managers. Luckily, Selenium already supports this new way of chromedriver discovery. The last version of Selenium Manager uses the CfT endpoints for chromedriver management. Therefore, if you are using Selenium Manager and Chrome, you must be updated to Selenium 4.11.0 to continue managing chromedriver automatically.

Automated browser management

Moreover, as of Selenium 4.11.0, Selenium Manager implements automated browser management based on CfT. In other words, Selenium Manager uses the CfT endpoints to discover, download, and cache the different CfT releases, making them seamlessly available for Selenium.

Let’s suppose we want to driver Chrome with Selenium (see the doc about how to start a session with Selenium). Before the session begins, and when the driver is unavailable, Selenium Manager manages chromedriver for us. This way, all the complexity related to CfT endpoints, driver versions, etc., is transparent, and we can rely on Selenium Manager to discover, download, and cache the proper driver for us.

In addition, and as a significant novelty starting on Selenium 4.11.0, if Chrome is not installed on the local machine when executing the previous line, the current stable CfT release is discovered, downloaded, and cached (in ~/.cache/selenium/chrome). But there is more. In addition to the stable CfT version, Selenium Manager also allows downloading of older versions of CfT (starting in version 113, which is the first version published as CfT).

To set a browser version with Selenium, we use a browser option called browserVersion. Until now, the value of this option had no effect when using the local browser since Selenium could not change what is installed in the system. But things are different with Selenium 4.11.0.

Let’s consider a simple example. Suppose we set browserVersion to 114 using Chrome options. In this case, Selenium Manager will check if Chrome 114 is already installed. If it is, it will be used. If not, Selenium Manager will manage (i.e., discover, download, and cache) CfT 114. And in either case, the chromedriver is also managed. Finally, Selenium will start Chrome to be driven programmatically, as usual.

But there is even more. In addition to fixed browser versions (e.g., 113, 114, 115, etc.), we can use the following labels for browserVersion:

stable: Current CfT version.
beta: Next version to stable.
dev: Version in development at this moment.
canary: Nightly build for developers.

When these labels are specified, Selenium Manager first checks if a given Chrome is already installed (beta, dev, etc.), and when it is not detected, CfT is automatically managed.

Under the hood

Selenium Manager is a CLI (command line interface) tool implemented in Rust and compiled for Windows, Linux, and macOS. The Selenium Manager binaries are shipped with each Selenium release. This way, each Selenium binding language invokes Selenium Manager to carry out the automated driver and browser management previously explained.

For most users, Selenium Manager should work silently and transparently. But if you want to play with Selenium Manager or use it for your own use case (e.g., to download drivers or CfT releases), you can get the Selenium Manager binaries from the Selenium main repository.

For instance, to manage Chrome/chromedriver, the Selenium Manager command we need to invoke from the shell is the following (notice that the flag --debug is optional, but it helps us to understand what Selenium Manager is doing):

> selenium-manager --browser chrome --debug
DEBUG Checking chromedriver in PATH
DEBUG Running command: chromedriver --version
DEBUG Output: ""
DEBUG chromedriver not found in PATH
DEBUG chrome detected at C:\Program Files\Google\Chrome\Application\chrome.exe
DEBUG Using shell command to find out chrome version
DEBUG Running command: wmic datafile where name='C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe' get Version /value
DEBUG Output: "\r\r\n\r\r\nVersion=115.0.5790.110\r\r\n\r\r\n\r\r\n\r"
DEBUG Detected browser: chrome 115.0.5790.110
DEBUG Reading metadata from https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json
DEBUG Required driver: chromedriver 115.0.5790.102
DEBUG Driver URL: https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/115.0.5790.102/win64/chromedriver-win64.zip
INFO Driver path: C:\Users\boni\.cache\selenium\chromedriver\win64\115.0.5790.102\chromedriver.exe
INFO Browser path: C:\Program Files\Google\Chrome\Application\chrome.exe

In this case, the local Chrome (in Windows) is detected by Selenium Manager. Then, using its version and the CfT endpoints, the proper chromedriver version (115, in this example) is downloaded to the local cache. Finally, Selenium Manager provides two results: i) the driver path (downloaded) and ii) the browser path (local).

Let’s consider another example. Now we want to use Chrome beta. Therefore, we invoke Selenium Manager specifying that version label as follows (notice that the CfT beta is discovered, downloaded, and stored in the local cache):

> selenium-manager --browser chrome --debug --browser-version beta
DEBUG Checking chromedriver in PATH
DEBUG Running command: chromedriver --version
DEBUG Output: ""
DEBUG chromedriver not found in PATH
DEBUG Checking chrome in PATH
DEBUG Running command: where chrome
DEBUG Output: ""
DEBUG chrome not found in PATH
DEBUG chrome has not been discovered in the system
DEBUG Reading metadata from https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions-with-downloads.json
DEBUG Required browser: chrome 116.0.5845.49
DEBUG Downloading chrome 116.0.5845.49 from https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/116.0.5845.49/win64/chrome-win64.zip
DEBUG chrome 116.0.5845.49 has been downloaded at C:\Users\boni\.cache\selenium\chrome\win64\116.0.5845.49\chrome.exe
DEBUG Reading metadata from https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json
DEBUG Required driver: chromedriver 116.0.5845.49
DEBUG Driver URL: https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/116.0.5845.49/win64/chromedriver-win64.zip
INFO Driver path: C:\Users\boni\.cache\selenium\chromedriver\win64\116.0.5845.49\chromedriver.exe
INFO Browser path: C:\Users\boni\.cache\selenium\chrome\win64\116.0.5845.49\chrome.exe

Troubleshooting in the bindings

If you want to get the Selenium Manager debugging information (as shown in the section before) when using the Selenium bindings languages, you can enable the logging capabilities of Selenium. Please visit the Selenium troubleshooting page for details.

Next steps

You can trace the work in progress in the Selenium Manager project dashboard. The following features to be implemented in Selenium Manager will continue the automated browser management mechanism, this time for Firefox and Edge. Stay tuned!

Blog: Introducing Selenium Manager

Fri, 04 Nov 2022 00:00:00 +0000

Most people’s first experience with Selenium ends up with an error message like this one:

java.lang.IllegalStateException: The path to the driver executable must be set by the webdriver.chrome.driver
system property; for more information, see https://chromedriver.chromium.org/. The latest version can be
downloaded from https://chromedriver.chromium.org/downloads

Then they have to search the web for instructions on what to do with the drivers they download.

Selenium: now with batteries included!

The Selenium project wants to improve the user experience, and one of the first steps is to help all users to simplify how they set up their environment. Configuring browser drivers has been for many years a task which users need to perform in order to have a working environment to run Selenium.

Setting up a browser driver once is not that complicated, but as browser release cycles got shorter, and now we have a new Chrome/Firefox/Edge version every 4-6 weeks, the task of keeping the browser driver in sync with the browser version is not that easy anymore.

Selenium Manager is a new tool that helps to get a working environment to run Selenium out of the box. Beta 1 of Selenium Manager will configure the browser drivers for Chrome, Firefox, and Edge if they are not present on the PATH.

To run a Selenium test with Selenium 4.6, you only need to have Chrome, Firefox, or Edge installed. If you already have browser drivers installed, this feature will be ignored. If you’d like to help us test it, though, delete your drivers or remove your third party driver manager and things should still “just work.” If they don’t, please file a bug report.

Future releases of Selenium Manager will eventually even download browsers if necessary.

Inspired by Open Source and the Selenium Community

Selenium Manager is not a completely new solution. Over the years, several third-party projects in the Selenium ecosystem emerged. Such as: WebDriverManager for Java, webdriver-manager for Python, webdrivers for Ruby, and WebDriverManager.Net for C#.

All these projects served as an inspiration and as a clear sign that the community needed this feature to be built-in Selenium. In addition, a survey done on January 2021 showed that most Selenium users want to get rid of the driver management problem. Plus, the fact that the driver installation page is by far the most visited one in the Selenium documentation.

Selenium Manager in detail

Selenium Manager is a CLI (Command-Line Interface) tool developed in Rust to allow cross platform execution. On its beta 1 version, Selenium Manager is invoked transparently by the Selenium bindings when no browser driver is detected on the PATH or no third party driver manager is being used.

You can also use Selenium Manager without the Selenium bindings. While we plan to do formal releases in the future, for now, the binaries can be found directly on the Selenium repository. Check the different parameters and options by running the following command:

$ ./selenium-manager --help

A quick example showing how ChromeDriver gets configured can be seen below:

$ ./selenium-manager --browser chrome
INFO /home/boni/.cache/selenium/chromedriver/linux64/106.0.5249.61/chromedriver

If you maintain a WebDriver based project and would like to use Selenium Manager as well, join us in our community channels and we would be happy to help. Also, if you are interested in contributing, for detailed instructions and information check the project’s README.

Next steps

Selenium Manager is still under development, features will be added and bugs fixed along with each release. However, you as a member of the Selenium community are key part on the future success of this new tool. Please report ideas or bugs through our issue tracker and join the conversation through our community channels. Looking forward to your feedback!

Happy testing!