We’re very happy to announce the release of Selenium 4.16.0 for
Javascript, Ruby, Python, and Selenium 4.16.1 for .NET, Java and the Grid.
-Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v118, v119, and v120 (Firefox still uses v85 for all versions)
Users may now opt in to Selenium Manager by specifying a browserVersion that is different from what is found on the System
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
@@ -210,7 +210,7 @@
We’re very happy to announce the release of Selenium 4.13.0 for Java,
Python, Javascript and the Grid; and 4.13.1 for .NET and Ruby.
Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v115, v116, and v117 (Firefox still uses v85 for all versions)
Reminder: this is the last version of Selenium with Java 8 support.
-Please upgrade to at least Java 11.
The location of Selenium Manager can be set manually in all bindings with SE_MANAGER_PATH environment variable.
Relevant improvements per language
Java
Deprecated setScriptTimeout(), use scriptTimeout()
Fixed several bugs related to logging driver output
We’re very happy to announce the release of Selenium 4.14.0 for Java,
Python, Javascript, Ruby, .NET and the Grid.
Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v116, v117, and v118 (Firefox still uses v85 for all versions)
If you are using Java, this release requires Java 11! (see post on Java 8 support)
Selenium supports automatic downloading and management of the Microsoft Edge browser
Relevant improvements per language
Java
Removed support for Async HTTP Client, the default is now the default Java library
Allow setting SSL context in client config for HttpClient
Today we’re happy to announce that Selenium 4.12.0 has been released!
By Titus Fortner @titusfortner |
@@ -225,7 +225,7 @@
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.
Selenium 4.11.0 Released!
Today we’re happy to announce that Selenium 4.11.0 has been released!
We’re very happy to announce the release of Selenium 4.11.0 for Java,
.NET, Ruby, Python, and Javascript as well as the Grid and Internet Explorer Driver.
-Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v113, v114, and v115 (Firefox still uses v85 for all versions)
Selenium Manager now locates the browser driver binary on PATH or the configured path, checks for potential incompatibilities, and gives better warning and error messages.
Nightly builds are being pushed for Ruby and Java. Support for other languages is coming soon.
Ignore process id match when finding the window handle - IE Mode on Edge. (#12246) (#12279)
Relevant improvements per language
Java
Make user defined SlotMatcher used everywhere in Grid code (#12240)
What's new in Selenium Manager with Selenium 4.11.0
Selenium 4.11.0 ships very relevant new features of Selenium Manager: support of Chrome for Testing (CfT) endpoints for chromedriver management and automated Chrome management (based also on CfT).
Selenium Manager now locates the browser driver binary on PATH or the configured path, checks for potential incompatibilities, and gives better warning and error messages.
Nightly builds are being pushed for Ruby and Java. Support for other languages is coming soon.
Ignore process id match when finding the window handle - IE Mode on Edge. (#12246) (#12279)
Relevant improvements per language
Java
Make user defined SlotMatcher used everywhere in Grid code (#12240)
What's new in Selenium Manager with Selenium 4.11.0
Selenium 4.11.0 ships very relevant new features of Selenium Manager: support of Chrome for Testing (CfT) endpoints for chromedriver management and automated Chrome management (based also on CfT).
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):
We’re very happy to announce the release of Selenium 4.11.0 for Java,
.NET, Ruby, Python, and Javascript as well as the Grid and Internet Explorer Driver.
-Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v113, v114, and v115 (Firefox still uses v85 for all versions)
Selenium Manager now locates the browser driver binary on PATH or the configured path, checks for potential incompatibilities, and gives better warning and error messages.
Nightly builds are being pushed for Ruby and Java. Support for other languages is coming soon.
Ignore process id match when finding the window handle - IE Mode on Edge. (#12246) (#12279)
Relevant improvements per language
Java
Make user defined SlotMatcher used everywhere in Grid code (#12240)
Selenium Manager now locates the browser driver binary on PATH or the configured path, checks for potential incompatibilities, and gives better warning and error messages.
Nightly builds are being pushed for Ruby and Java. Support for other languages is coming soon.
Ignore process id match when finding the window handle - IE Mode on Edge. (#12246) (#12279)
Relevant improvements per language
Java
Make user defined SlotMatcher used everywhere in Grid code (#12240)
We’re very happy to announce the release of Selenium 4.16.0 for
Javascript, Ruby, Python, and Selenium 4.16.1 for .NET, Java and the Grid.
-Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v118, v119, and v120 (Firefox still uses v85 for all versions)
Users may now opt in to Selenium Manager by specifying a browserVersion that is different from what is found on the System
\ No newline at end of file
diff --git a/blog/2024/_print/index.html b/blog/2024/_print/index.html
index ff5c411f6c18..738cbb08ee5e 100644
--- a/blog/2024/_print/index.html
+++ b/blog/2024/_print/index.html
@@ -153,11 +153,11 @@
We’re very happy to announce the release of Selenium 4.18.0 and 4.18.1 for
Javascript, Ruby, Python, .NET, Java and the Grid!
Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v120, v121, and v122 (Firefox still uses v85 for all versions)
Selenium Manager records usage has been decreased to reduce impact on users.
Chrome headless changed the name of the browser to reflect that it is not actually chrome; Selenium now handles this seamlessly,
-but you should still switch to --headless=new (see: Headless is going away)
Noteworthy changes per language
Java
Enabling Grid to use self-signed certificate for debugging
Added explicit target locator events to the listener support classes in WebDriverListener.
Add missing event handlers for TargetLocator interface in WebDriverListener.
Several BiDi additions: Browsing context destroyed event, Network intercept commands, command continuewithAuth, between others.
We’re very happy to announce the release of Selenium 4.17.0 for
Javascript, Ruby, Python, .NET, Java and the Grid!
Links to everything can be found on our downloads page.
Highlights
Chrome DevTools support is now: v119, v120, and v121 (Firefox still uses v85 for all versions)
Chrome headless changed the name of the browser to reflect that it is not actually chrome; Selenium now handles this seamlessly,
-but you should still switch to --headless=new (see: Headless is going away)
Noteworthy changes per language
Java
Remove deprecated event listener classes; update to EventFiringDecorator and WebDriverListener classes
Allow disabling Grid UI
Deprecated FirefoxBinary class and legacy Error Codes
Deprecated HTML5 features for offline storage, location, and network connection
No longer accepting session requests with desiredCapabilities keyword
The easiest way to clickbait a blog post about automated testing is to compare Selenium against another tool in the space with a catchy title especially when it talks down about the incumbent.
Unfortunately, this can lead to muddying the waters of which features are available in any of the products out there especially when we compare apples to apples.
Selenium has always been a great tool for browser automation. Fortunately for the project, it has become the tool of choice for testing web applications for nearly 2 decades. The area this project has focused on is building out the hard parts of browser automation that are increasingly difficult. Stable APIs and scalability of the infrastructure to run Selenium has always been the priority of the project. It hasn’t focused on how people test with it because there are very good test frameworks out there and having to do it for 5 different languages is a non-trivial amount of engineering effort.
However, some particular misconceptions regularly reappear across these blog posts.
It’s too hard to set up browsers and drivers compared to Playwright and Cypress
This used to be true in the past as you had to download the drivers. This wasn’t too bad for GeckoDriver and SafariDriver as they could handle browser upgrades gracefully. On the other hand, you need to update the drivers for Chromium-based browser for every new release.
For over a year now, Selenium handles this automatically. If it can’t find a ChromeDriver or EdgeDriver, it will download it using Selenium Manager. Since its first release it has improved a lot and it is now probably the best in class since the latest versions of Selenium will even download browsers if it can and use that. Compared to Playwright and Cypress you don’t need to update your dependency on Selenium to update browsers and drivers, you still use the same browsers as your customers, and switching versions becomes a breeze: you don’t also have to change the test framework you’re using. And, let’s not forget that it uses the browser that Google recommends you use for testing.
Setting up a test runner is hard work where Playwright and Cypress have it built in…
Well… maybe? Setting up E2E test frameworks with Selenium isn’t as difficult as some might suggest. The hard part really is making sure that the driver is in the right place and we’ve solved that as discussed above. Once that’s done, Selenium’s approach allows you to use whichever test runner you’re most comfortable with. If you’d like a “batteries included” approach, with Selenium tightly integrated with the test runner, then one of the many projects that use Selenium, such as SeleniumBase, Nightwatch, Serenity, and so on, might be the right tool for you.
One thing to note is that Playwright is the only multi-language browser automation framework like Selenium. However, if you don’t use TypeScript or JavaScript you will still need to do the setup of the test runner yourself. Some testing frameworks have plugins that automatically set up the fixtures you might need. In the JavaScript/TypeScript space if you really need a built-in test runner there are downstream projects like NightwatchJS and tangential projects like WebdriverIO. Downstream projects use our libraries and tangential projects have their own libraries but still follow the WebDriver standard.
Playwright and Cypress can do network interception and allow me to write event-driven code unlike Selenium
Selenium has been able to offer this since Selenium 4 came out. It’s so good that even Playwright suggest you use it for scaling your tests. The Selenium Project won’t be removing this anytime soon as we are dependent on WebDriver BiDi specification being implemented for those features to replace them. Even then Selenium has a history of trying to make sure that upgrades don’t break anything without sufficient warning. It’s why each language provides high-level wrappers, such as the NetworkInterceptor, that isolate your tests from the underlying technology being used.
Summary
As we have seen from the above Selenium is still as good as the products out there. One thing that is different for Selenium from Cypress or Playwright is that we’re a volunteer-driven project and not commercially backed. Want to help us out? Why not write a blog post about how you’re using the features above or post on social media how these features make your lives easier?
