Selenium – releases

Blog: Selenium 4.18 Released!

Mon, 19 Feb 2024 00:00:00 +0000

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.
- See all changes

JavaScript
- Several BiDi additions: Browsing context destroyed event, realm destroyed event, command continuewithAuth, between others.
- See all changes

.NET
- Fix protocol cdp version for RemoteWebDriver.
- Fix network response data encoding.
- Explicitly support passing the full path to driver in Service constructor
- See all changes

Python
- Python for nightly releases
- See all changes

Ruby
- See all changes

Rust
- Add timestamps to Selenium Manager logs
- Selenium Manager decreases frequency of statistics reporting
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

If you want to render content fetched from the GitHub API, please create a personal access token and set it as an environment variable named SELENIUM_CI_TOKEN. More information about token scopes can be seen at available scopes GitHub docs

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Team Members

Thanks as well to all the team members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium 4.17 Released!

Tue, 23 Jan 2024 00:00:00 +0000

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)
Selenium Manager records usage set environment variable SE_AVOID_STATS to "true" to avoid sending information.
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
- See all changes

JavaScript
- Remove deprecated headless methods and associated references
- Implemented remote file downloading
- See all changes

.NET
- Improvements to the new logging implementation
- Removed previously deprecated code
- See all changes

Python
- Updated WPEWebKit support
- Removed previously deprecated code
- Deprecated FirefoxBinary and several outdated FirefoxProfile methods
- See all changes

Ruby
- Logger defaults output to stderr instead of stdout
- See all changes

Rust
- Use latest browser from cache when browser path is not discovered
- Throw a descriptive message when error parsing JSON from response
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Team Members

Thanks as well to all the team members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium 4.16 Released!

Wed, 06 Dec 2023 00:00:00 +0000

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
All bindings now log Selenium information

Noteworthy changes per language

Java
- Improve Grid usage of Selenium Manager by always allowing browser version of “stable”
- Implement CDP script pinning for Chrome-based browsers
- Allow reusing devtools instance with JDK 11 client
- Moved org.openqa.selenium.remote.http.jdk to selenium-http
- See all changes

JavaScript
- Fix logging levels in http.js and webdriver.js
- See all changes

.NET
- Allow overriding default Actions duration
- Remove System.Drawing.Common as package dependency
- See all changes

Python
- Remove deprecated Safari parameters for reuse_service and quiet
- Fix bug to allow Remote WebDriver to use custom Chrome-based commands
- See all changes

Ruby
- Added initial typing support with rbs files
- Fix bug preventing Selenium Manager from working with Unix and Cygwin
- See all changes

Rust
- Use online mapping to discover proper geckodriver version
- Fix webview2 support when browser path is set
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Team Members

Thanks as well to all the team members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

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: Selenium 4.15 Released!

Wed, 01 Nov 2023 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.15.0 for Java, Javascript, Ruby, .NET and the Grid; 4.15.2 for Python. Links to everything can be found on our downloads page.

Highlights

Chrome DevTools support is now: v117, v118, and v119 (Firefox still uses v85 for all versions)
Implemented Remote File Downloads
Selenium Manager supports webview2, Firefox ESR and Driver and Browser Mirrors

Noteworthy changes per language

Java
- Numerous BiDi implementations
- Remove CDP version dependencies in the server
- Selenium Manager now gets copied to cache directory instead of being used from temp directory
- See all changes

JavaScript
- Replaced calls to console.log with managed loggers
- Added several BiDi methods
- See all changes

.NET
- Improved nuget packages metadata
- Allows starting service object directly
- See all changes

Python
- Remove selenium manager accommodation for Conda
- See all changes

Ruby
- See all changes

Rust
- Included debug and split-debuginfo in dev profile
- Changed windows target to stable-i686-pc-windows-gnu
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

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: Selenium 4.13 Released!

Mon, 25 Sep 2023 00:00:00 +0000

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
- Removed a number of previously deprecated methods
- See all changes

JavaScript
- Minor bug fixes
- See all changes

.NET
- Users can now start a service before creating the driver object instance
- Removed Microsoft.IdentityModel.Tokens as dependency
- Fixed several bugs and made improvements to DevTools implementations
- See all changes

Python
- Removed deprecated headless methods
- Fixed bug preventing using performance logging in Chrome and Edge
- See all changes

Ruby
- Fixed bug preventing using performance logging in Chrome and Edge
- Users can now start a service before creating the driver object instance
- Removed deprecated driver extensions for location and network connection
- See all changes

Rust
- Various bug fixes for improved Selenium Manager functionality
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium 4.14 Released!

Mon, 25 Sep 2023 00:00:00 +0000

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
- Several logging message improvements
- See all changes

JavaScript
- See all changes

.NET
- Saving screenshots with different image formats is deprecated
- Removed IdentityModel dependency
- See all changes

Python
- Fix bug that didn’t close log_output in Service classes
- See all changes

Ruby
- Provide public access to atom scripts
- See all changes

Rust
- Automated Edge management
- Recognizes and handles webview2
- Locates existing Chromium browsers when specifying Chrome
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium 4.12.0 Released!

Thu, 31 Aug 2023 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.12.0 for Java, .NET, Ruby, Python, and Javascript as well as the Grid. Links to everything can be found on our downloads page.

Highlights

Chrome DevTools support is now: v114, v115, and v116 (Firefox still uses v85 for all versions)
Quite a few fixes for Selenium Manager, and now with Firefox browser management! Read about all the new Selenium Manager features
.NET only explicitly targets netstandard2.0
Python no longer supports Python 3.7
Ruby no longer supports :capabilities arguments for local drivers (must use :options now)

Relevant improvements per language

Java
- Several improvements in working with Selenium Manager
- Allow deleting remote downloaded files from grid (#12501)
- Removed deprecated UNEXPECTED_ALERT_BEHAVIOR, BROWSER_LOGFILE, createPointerDown, createPointerUp and JWP /file endpoint
- Deprecated disableNativeEvents and Remote Response status field
- See all changes

JavaScript
- Fix how browsers and drivers are discovered (#12456)
- See all changes

.NET
- Several big fixes for improving DevTools execution (#12486, #12614, #12592, #12591)
- Bug fix for how driver location is specified in Service class (#12473)
- See all changes

Python
- Support Selenium Manager in conda installs (#12536)
- Several bug fixes in Typing suggestions (#12477, #12464)
- allow setting http client certifications with REQUESTS_CA_BUNDLE env (#11957)
- Fix bugs for ElementScrollBehavior, sending keys with long strings and getting capabilities from options
- See all changes

Ruby
- Fix bug preventing good error messages in Selenium Manager when stdout empty
- Fix bug with Firefox not loading net/http library by default (#12506)
- See all changes

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

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: Selenium 4.11.0 Released!

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

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)
Support for Chrome for Testing (CfT) through Selenium Manager. Read more at the new Selenium Manager features blog post.
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)
- Add support for FedCM commands (#12096)

JavaScript
- BiDi Add Network module events (#12197)

.NET
- Implementation of event wrapped shadow root element (#12073)
- Allow setting a different pointer, keyboard, or wheel on input device (#11513)
- Add move to location method to Actions (#11509)
- Add support for Safari Technology Preview (#12342)
- Fix error when we send non-base64 data for fetch command (#12431)
- Fix continueResponse method in CDP (#12445)

Python
- removed redundant attributes capabilities and set_capability in wpewebkit/options.py (#12169)
- improve driver logging, implement log_output() for flexibility and consistency of driver logging (#12103)
- let users pass service args to IE driver (#12272)
- Expose WPEWebKitService and WebKitGTKService in the public API
- Remove deprecated ActionChains.scroll(...)
- Add creation flag for windows in selenium_manager (#12435)

Ruby
- Made network interception threads fail silently (#12226)
- Remove deprecated code (#12417)

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

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: Building Selenium

Mon, 12 Jun 2023 00:00:00 +0000

One of the things that we knew from the very beginning of the Selenium project was that people like to code in more than one language. Some people love a bit of JS, others Ruby, and still others prefer C# or Java.

To complicate matters, there’s plenty of pieces we want to share between the language bindings you’ll be using. Examples include the “atoms” (re-usable pieces of javascript that perform common functions – such as “isDisplayed” or “getAttribute” – that we want to work the same way no matter which language you prefer to write tests in), things like our CDP support, which uses shared files that describe all the available functions we can call, and the new Selenium Manager, which is written in Rust, but we bundle with each of the language bindings.

The process of converting the source code and other artefacts (such as the atoms) together into the artefacts we distribute (such as the Selenium Server, or the language bindings) is called the “build”. There are plenty of build tools out there. If you’re a java developer, you’ve probably come across Maven or Gradle. If you’re a JS hacker, then perhaps something like npm or yarn is something you’ve used. If you’re a C developer (there are still plenty out there!) then you’re likely using make or CMake.

The problem with many build tools is that they’re focused on one language. Npm is great, but it’s a terrible choice for a Java project. Gradle is fine, but not if you’re working in Ruby.

Why is this a problem? Because in the Selenium codebase we want to support multiple different languages, and we want to be able to “stitch” them together into a single cohesive whole. For example, the Selenium jars contain a fairly large amount of JS. The Ruby gems do too.

What we want is a single build tool that can cope with lots of different languages, so we can weave our build into something where we only need that one tool.

Enter Bazel. This was a build tool originally developed by Google, but which is now Open Source and increasingly widely used. Bazel itself is relatively limited in what it can do, but it can be extended easily using “rulesets” that allow it to support everything we need, and more!

Bazel is one of a new generation of build tools, and focuses on exposing how each part of the build process relates to the other parts. You could imagine drawing a chart, with each thing we need to compile (eg. Selenium Manager, or the atoms, or one of the jars we ship) connected by lines to other parts that they depend upon. In Computer Science, that chart is called a “graph”, and because each line has a direction (“this thing depends upon that thing”) we call it a directed graph. Because we can’t depend on something that depends on itself, we can introduce a “cycle”. Bazel is a build tool designed to work with these “directed acyclic graphs”.

One nice thing about these graphs is that there are well-known ways to figure out which parts of the build can be performed in parallel. A modern computer has a CPU with many (4, 8, 16!) cores, plenty of memory, and fast SSDs: it can comfortably perform many tasks at the same time. So Bazel takes advantage of this, running as many parts of the build at the same time as it can. This makes our builds significantly faster than they used to be!

Better yet, Bazel makes us list all the things that each part of the build depends on. Not just the source code, but which versions of which tools we’re using. That makes it a lot easier for a developer new to the project to get started: they just need to clone our repo, make sure they have Bazel installed, and the build process will take care of making sure that they have everything they need (although that first build may be very slow as everything that’s needed will be downloaded from the Net). That’s not just nice for people new to the project, it’s nice for the existing developers. They no longer need to know how to install and set up toolchains that they may not be familiar with – they just run the build.

Using the “build graph”, Bazel is able to tell which pieces of code in the Selenium source code depend on which other parts. This means that although we can tell Bazel to “run all our tests” when we make a change, it’s smart enough to know that it only needs to run those tests which are actually affected by a change. You can see this in action in this video, but needless to say, this can save us a huge amount of time! We can also ask Bazel to re-run flaky tests

But there’s another advantage of describing all the things we need for a build. Since we’ve described everything we need to Bazel, and how all the pieces fit together, there’s no need to just run the build on our own machines. We’re working with EngFlow to make use of their build grid. Rather than just running a small number of things at the same time on our machines, we can run many times that on their build grid. Our builds there are incredibly fast!

So, that’s why we use Bazel on our project: it supports all the languages we want to use in a single tool, allows us to not think about how to set up our development machines, runs builds incredibly quickly, and we can make use of build grids to build things even faster.

Blog: Java 8 support in Selenium

Fri, 09 Jun 2023 00:00:00 +0000

“If it ain’t broke, don’t fix it” is a saying you may have heard, but sometimes it’s necessary to move on from our old favorites. That’s why we’re announcing that Selenium will stop supporting Java 8 on September 30, 2023. This applies for both the Java bindings and the Selenium Grid.

Selenium has long supported Java 8, but as technology evolves, so must we. One of the primary reasons for this change is that Java 8 reached the end of active support over a year ago. In addition, our default HTTP Client has not had a major release in several years, and a bug has been found that we can not fix. We have decided to move to the native Java HTTP Client, but it requires using Java 11 or greater. The sooner we make this change, the sooner we can avoid dealing with this issue.

Our new minimum version will be Java 11. September 30, 2023 is also the end of active support for Java 11. However, we want to take a cautious and conservative path forward, and not force our users to make the big jump from Java 8 to Java 17, as we understand the community might need longer to move to that version. We will revisit this topic in the future to announce the plan to support Java 17 as a minimum version.

We understand that this change may require some of our users to make adjustments, but we believe that it’s a necessary step for the continued growth of Selenium. Please take some time to check your infrastructure and ensure you’re running on Java 11 or higher. We understand that some may be hesitant or may find it difficult to make the switch, but we believe it will pay off in the long run.

Please let us know your questions, concerns, and feedback through our community chat.

Happy testing!

Blog: Selenium 4.10.0 Released!

Wed, 07 Jun 2023 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.10.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: v112, v113, and v114 (Firefox still uses v85 for all versions)
Selenium Manager supports proxy usage by using the proxy information set in the browser options.
Adding support for webview2 in Edge for Java, JavaScript, and Ruby
Error messages across bindings now include links to the Selenium documentation.
Overhaul of the service classes and logging output options.
Logger in Ruby updated default behavior to match other languages and added features to improve filtering types of logging.
Python - removal of several sections of deprecated code.
- Most of them were arguments that can be set in the Options classes (browser values) or Service classes (browser driver values).
- They have been deprecated since the first Selenium 4 release

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

Selenium

`SELENIUM_CI_TOKEN` not set

Selenium Docs & Website

`SELENIUM_CI_TOKEN` not set

Docker Selenium

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium 4.9.0 Released!

Fri, 21 Apr 2023 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.9.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: v110, v111, and v112 (Firefox still uses v85 for all versions)
Maven BOM for the Java bindings.
Remote file downloads are now possible through Selenium Grid.
First steps taken to phase out CDP in Firefox and replace it with the BiDi implementation.
InvalidSelectorException now extends WebDriverException instead of NoSuchElementException.
Selenium Manager uses information set in the browser options to get the correct browser driver.
A sub-path can be set in Selenium Grid to have a custom Grid url.
Complete removal of Json Wire Protocol support in Java and Grid.

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Headless is Going Away!

Sun, 29 Jan 2023 00:00:00 +0000

Headless is an execution mode for Firefox and Chromium based browsers. It allows users to run automated scripts in headless mode, meaning that the browser window wouldn’t be visible. In most of Selenium’s bindings there is a convenience method to set this execution mode while setting the browser options. However, Selenium 4.8.0 will be deprecated this method and now users need to set it through arguments when setting the browser options.

Why is Selenium doing this?

Chromium based browsers have now two different headless modes (the original one, and one with more capabilities added in 2022). When a user sets headless to true via the convenience method in Selenium, it is using the initial method provided by Chromium based browsers.

By deprecating the convenience method (and removing it in Selenium 4.10.0), users will be in full control to choose which headless mode they want to use.

What are the two headless modes?

The traditional --headless, and since version 96, Chrome has a new headless mode that allows users to get the full browser functionality (even run extensions). Between versions 96 to 108 it was --headless=chrome, after version 109 --headless=new.

Using --headless=new should bring a better experience when using headless with Selenium.

Thanks to Michael Mintz for the detailed explanation!

Check more details about the new headleass mode at the official Chrome blog.

How can I set headless mode from now on?

In short, users can add the headless mode they want to use through arguments in browser options.

Before

ChromeOptions options = new ChromeOptions();
options.setHeadless(true);
WebDriver driver = new ChromeDriver(options);
driver.get("https://selenium.dev");
driver.quit();

let driver = await env
 .builder()
 .setChromeOptions(new chrome.Options().headless())
 .build();
await driver.get('https://selenium.dev');
await driver.quit();

// C# did not have a convenience method

options = Selenium::WebDriver::Chrome::Options.new
options.headless!
driver = Selenium::WebDriver.for :chrome, options: options
driver.get('https://selenium.dev')
driver.quit

options = ChromeOptions()
options.headless = True
driver = webdriver.Chrome(options=options)
driver.get('http://selenium.dev')
driver.quit()

After

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new");
WebDriver driver = new ChromeDriver(options);
driver.get("https://selenium.dev");
driver.quit();

let driver = await env
 .builder()
 .setChromeOptions(options.addArguments('--headless=new'))
 .build();
await driver.get('https://selenium.dev');
await driver.quit();

var options = new ChromeOptions();
options.AddArgument("--headless=new");
var driver = new ChromeDriver(options);
driver.Navigate().GoToUrl("https://selenium.dev");
driver.Quit();

options = Selenium::WebDriver::Options.chrome(args: ['--headless=new'])
driver = Selenium::WebDriver.for :chrome, options: options
driver.get('https://selenium.dev')
driver.quit

options = ChromeOptions()
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
driver.get('http://selenium.dev')
driver.quit()

If you have any questions or comments, please reach out through any of all the available options shown at our support page.

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Blog: Selenium 4.8.0 Released!

Mon, 23 Jan 2023 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.8.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: v107, v108, and v109 (Firefox still uses v85 for all versions)
Large JS executions have the name as a comment to help understand what payload being sent to/from server/driver.
Deprecation of headless convenience method. Read more about in the headless blog post.
Ruby overhauls Options classes (again)
Initial BiDi support in JavaScript, Ruby, and improvements in Java.
We’re continuing to remove Legacy Protocol classes in Java and Grid.
Accommodate ability to specify sub-paths in Grid.
Plus various language specific bug fixes; see the full list of changes in the Changelogs

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

Blog: Selenium 4.7.0 Released!

Fri, 02 Dec 2022 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.7.0 for Java, .NET, and Javascript as well as the Grid and Internet Explorer Driver; for Ruby use 4.7.1, and Python 4.7.2. Links to everything can be found on our downloads page.

Highlights

Chrome DevTools support is now: v106, v107, and v108 (Firefox still uses v85 for all versions)
Selenium Manager now supports IE Driver & has improved error logging.
Using Edge in IE Mode no longer requires ignoring zoom levels.
We’re continuing to remove Legacy Protocol classes in Java and Grid.
Java adds WebDriver-BiDi support for Logging.
.NET includes an explicit target for net6.0 framework.
Ruby is now publishing nightly gems
Plus various language specific bug fixes; see the full list of changes in the Changelogs

Contributors

Special shout-out to everyone who helped the Selenium Team get this release out!

`SELENIUM_CI_TOKEN` not set

Thanks as well to all the Selenium Team Members who contributed to this release:

`SELENIUM_CI_TOKEN` not set

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!

Blog: Selenium 4.6.0 Released!

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

We’re very happy to announce the release of Selenium 4.6.0 for Java, .NET, Python, Ruby, and JavaScript bindings as well as the Grid and Internet Explorer Driver. Links to everything can be found on our downloads page.

Highlights

Adding support for CDP released in Chrome v105, v106, and v107, while v104 was removed
Initial implementation of Selenium Manager across bindings
Improvements to the new Java HTTP 11 client and important Grid fixes.
Observability enabled in the Docker-Selenium images.
Various language specific bug fixes; see the full list of changes in the Changelogs

Huge thanks to all the contributors who made this version possible:

`SELENIUM_CI_TOKEN` not set

Blog: Selenium 4.5.0 Released!

Wed, 28 Sep 2022 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.5.0 for Java, .NET, Python, Ruby, and JavaScript bindings as well as the Grid and Internet Explorer Driver. Links to everything can be found on our Downloads Page.

Highlights

Adding support for CDP released in Chrome v105 and v106, while v102 and v103 were removed
Updates to Select functionality
Improved experience for Firefox Add-ons
IE driver automatically uses Edge in IE Mode if IE is not present
Java 11 HTTP Client supported for Java users running Java versions 11+
Various language specific bug fixes; see the full list of changes in the Changelogs.

Huge thanks to all the external contributors who made this version possible:

`SELENIUM_CI_TOKEN` not set

Blog: Using Java 11+ HTTP Client in Selenium 4.5.0 and beyond

Fri, 16 Sep 2022 00:00:00 +0000

Current HTTP client used in Selenium

Selenium uses an HTTP client and associated WebSocket client for multiple purposes

To send commands to the WebDriver
To send commands from the Selenium client library to the Grid
For various Grid components to communicate with each other depending on the Grid mode
To create ChromeDevTools protocol and BiDi protocol sessions

Currently, Selenium uses AsyncHttpClient. AsyncHttpClient is an open-source library built on top of Netty. It allows the execution of HTTP requests and responses asynchronously. Additionally it also provides WebSocket support. Hence it is a good fit.

Why does Selenium want to move to Java 11+ HTTP Client?

While AsyncHttpClient provides the required functionality, the open-source project is not been actively maintained since June 2021. It coincides with the fact that Java 11+ provides a built-in HTTP and WebSocket client. Selenium can utilize it to replace AsyncHttpClient.

Currently, Selenium Java supports Java 8. Selenium has plans to upgrade the minimum version supported to Java 11. However, it is a sizeable effort. Aligning it with major releases and accompanied announcements is crucial to ensure the user experience is intact.

The Selenium server runs great on Java 11+ already, so while we plan to make that the minimum version in a future release, for now we plan to introduce optional components that can take advantage of modern Java releases.

So as a first step towards this move, the Java 11+ HTTP client from Selenium 4.5.0 and above.

Using Java 11+ HTTP Client in Selenium

Prerequisites:

Project configured to use Java 11+
Using Selenium 4.5.0 as a minumum version, find the latest in the downloads page.

Integrating the Java 11+ client

Java 11+ HTTP client sits in its own artifact. It can be imported into projects that use Java 11+.

Add the artifact the POM

Add the follow dependencies to your pom.xml

<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>4.5.0</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-http-jdk-client</artifactId>
<version>4.5.0</version>
</dependency>

NOTE: In the dependencies above version 4.5.0 is shown, however we recommend you to check the downloads page to use the latest version released. Make sure the versions used are matching.

Set the system property

Set the system property to indicate that Java 11+ Http client needs to be used. By default, it uses the AsyncHttpClient.

 System.setProperty("webdriver.http.factory", "jdk-http-client");

You are all set up to leverage the newly supported client. The user-experience remains the unchanged. Everything else works as expected.

Using the Java 11+ client in Grid

To do that, you will need to download the selenium-http-jdk-client jar file and use the --ext flag to make it available in the Grid jar’s classpath.

The jar file can be downloaded directly from repo1.maven.org and then start the Grid in the following way:

java -Dwebdriver.http.factory=jdk-http-client -jar selenium-server-4.5.0.jar -—ext selenium-http-jdk-client-4.5.0.jar standalone

An alternative to downloading the selenium-http-jdk-client jar file is to use Coursier.

java -Dwebdriver.http.factory=jdk-http-client -jar selenium-server-4.5.0.jar —-ext $(coursier fetch -p org.seleniumhq.selenium:selenium-http-jdk-client:4.5.0) standalone

If you are using the Hub/Node(s) mode or the Distributed mode, setting the -Dwebdriver.http.factory=jdk-http-client and —-ext flags needs to be done for each one of the components.

NOTE: In the dependencies above version 4.5.0 is shown, however we recommend you to check the downloads page to use the latest version released. Make sure the versions used are matching.

Huge thanks to Simon Stewart (@shs96c) for making this possible with his contribution!

Blog: Selenium 4.4.0 Released!

Tue, 09 Aug 2022 00:00:00 +0000

We’re very happy to announce the release of Selenium 4.4.0. We’re shipping this for Java, .Net, Python, Ruby, and JavaScript, so if you’re using any of those languages, go and grab it from your package manager of choice!

Some of the main highlights are:

Adding support for CDP released in Chrome v104, while v101 was removed
Virtual authenticator feature was completed across languages.
All language bindings will throw an error when w3c: false is set in ChromeOptions
Improved health checks and requests with non W3C locators for Relay Nodes in Grid

Check the complete changelog and download the artifacts at the Selenium 4.4.0 release in GitHub or directly from the Selenium site.

Huge thanks to all the contributors who made this version possible:

`SELENIUM_CI_TOKEN` not set

Blog: Selenium 4 Release Candidate

Mon, 06 Sep 2021 00:00:00 +0000

We’re very happy to announce the first release candidate of Selenium 4. We’re shipping this for .Net, Java, Python, Ruby, and JavaScript, so if you’re using any of those languages, go and grab it from your package manager of choice!

This release is the result of a lot of work by the Selenium team project, but most importantly, all the Selenium community who tried our beta releases, and gave us great and valuable feedback.

#Selenium 4 Release Candidate for #ruby is now available! There should be fewer problems running against latest versions of browsers now than with Selenium 3. Please update and let us know of any problems so we can get the production release out the door. https://t.co/JWbwDRPcj4
— Titus Fortner (@titusfortner) September 1, 2021

So, big news: #Selenium 4.0 RC1 has just been released! The .NET bindings are available via #NuGet, or you can find them at our new binary release point, https://t.co/CSNK7K47ue. We're closing in on a final, stable 4.0 release, so if you haven't tried it before now, you should!
— Jim Evans (@jimevansmusic) September 1, 2021

#Selenium 4 RC1 is out! The #python bindings are available at https://t.co/B4zKI6JQkA pic.twitter.com/kMlDM4ad7I
— David @automatedtester@mastodon.social (@AutomatedTester) September 2, 2021

Hurrah! #selenium4 RC1 is out, and the Java bindings have been released! Grab them from your favourite maven repo, or download the binaries from https://t.co/XUcv7RzbzL pic.twitter.com/E9T1ZTZ9jd
— Simon Mavi Stewart (@shs96c) September 2, 2021

@SeleniumHQ 4 RC 1 is out! This means that Selenium 4 is getting closer and closer 🎉🎉
Try out the new Grid through our @docker images -> https://t.co/lGUrZAQneJ pic.twitter.com/BzZxPn3p0y
— Diego Molina (@diegofmolina) September 6, 2021

One thing you may want to do to get ready for the update (which you can do before updating the dependency itself!) is to update the drivers you need. In particular, please update geckodriver to 0.29.1 or later.

Most of the new features in Selenium 4 are mentioned in this blog entry, but the main highlights are:

Relative locators, for finding elements using terms that make sense to us humans.
The ability to intercept network traffic
Authentication with basic or digest authentication.

If this sounds interesting, please download the release candidate from your favourite package manager (maven, nuget, npm, pip, or the gem), or directly from the Selenium site.

Blog: Selenium 4 Beta 1 Released

Mon, 15 Feb 2021 00:00:00 +0000

We’re very happy to announce the release of the first beta of Selenium 4. We’re shipping this for Java, .Net, Python, Ruby, and JavaScript, so if you’re using any of those languages, go and grab it from your package manager of choice!

This has been the culmination of a lot of work by so many people, not only the project TLC, but also of literally hundreds of people: 205 since we released Selenium 3.141.59, at the last count. A big thank you to everybody who’s helped make this possible!

So, what’s changed since Selenium 3? The answer is both “not much” and also “almost everything”.

By “not much”, I mean that if your tests are working with Selenium 3 right now, you should be able to just upgrade your dependency to Selenium 4. You will find that things that were marked “deprecated” are now gone, but the advantage of the long time between the last Selenium 3 release and this is that you’ve had plenty of time to try and find alternatives.

If this doesn’t work, please let us know! We’ve worked hard to ensure compatibility between the releases, but it’s possible we may have missed some things.

By “almost everything”, I mean that under the covers there have been substantial changes. We’ve rewritten the Selenium server to allow it to work not only in the familiar “standalone” and “hub and node” modes, but also in a new “distributed” mode, which makes it signifcantly easier to deploy to something such as Kubernetes in a way that scales well.

The new server is also wired up with support for OpenTelemetry and exposes a GraphQL endpoint, so that figuring what’s going on in the Grid, and tracking down what’s gone wrong if something happens, is easier than ever.

Not all the changes are server-side. We recently wrote about the new features in Selenium 4 that you can use in your tests, but some of the main highlights are:

Relative locators, for finding elements using terms that make sense to us humans.
The ability to intercept network traffic
Authentication with basic or digest authentication.

We’ll be telling you more about these features in later blog posts, and as we improve our documentation.

If this sounds interesting, please download the beta from your favourite package manager (maven, nuget, npm, pip, or the gem), or directly from the Selenium site.

Blog: Selenium 4.0 Alpha 6 is out!

Mon, 01 Jun 2020 00:00:00 +0000

We are very pleased to announce the release of Selenium 4.0 Alpha 6.

All the information can be seen in different tweets from the project contributors, here they are all in one place:

Happy Friday! I've just pushed Selenium 4.0a6 for Java. There's a lot of nice changes:

* Full remoting of the CDP protocol across the Grid
* The skeleton of our GraphQL support
* Better configuration options, especially for Nodes, via TOML
* A bajillion improvements & fixes

1/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

As ever, this release is the product of hard work and contributions not only from the core team (special thanks to @barancev and @diemol. You've done amazing work!) but also from a host of other people. In that spirit, I'd like to thank… 2/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

In no particular order:

* Amit Bhoraniya
* @bongosway
* Gerry Gao
* Sridhar Upputuri
* John Chen
* @alb_i986
* Rahul Shah
* @ulfjack

I've linked to the twitter handle where I know it. Give 'em a high five! Selenium wouldn't be possible without the help of the community! 3/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

I'm hoping that the next alpha will be the last alpha. The "big ticket" items remaining are:

* Provide nice APIs to take advantage of the CDP
* Flesh out the GraphQL support
* A nice UI to take advantage of the GraphQL endpoint
* Robustness work in the Grid

4/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

You can come and join in the fun by either heading over to the GitHub project and picking a task (https://t.co/2ifj6CkeEV) or (and!) coming to have a chat on Slack https://t.co/4aEDqyI6gq 5/5
— Simon Mavi Stewart (@shs96c) May 29, 2020

I have just tagged #Selenium 4a6 on GitHub. It's got a lot of nice cleanups as we edge closer to a proper #Selenium 4 release!
— David @automatedtester@mastodon.social (@AutomatedTester) May 28, 2020

selenium-webdriver 4.0.0.alpha6 has just been released. The biggest change is an experimental support for Chrome DevTools protocol! Read more in changelog https://t.co/1l2XYkaEfB.#selenium #ruby #devtools
— Alex Rodionov (@p0deje) May 28, 2020

Happy hacking!

Blog: Selenium 3.0: Out Now!

Thu, 13 Oct 2016 00:00:00 +0000

We are very pleased to announce the release of Selenium 3.0. If you’ve been waiting for a stable release since 2.53.1, now’s your chance to update. And if you do, here is what you’ll find:

As we’ve said before, for users of the WebDriver APIs this is a drop-in replacement. You’ll find that modern browsers, such as Chrome and Edge will continue to work just as before, and we’ve taken the opportunity to fix some bugs and improve stability. Selenium Grid users may require updates to their configuration as the json config file format has been updated, as have some of command line parameter options, but the upgrade should also be smooth.

The major change in Selenium 3.0 is we’re removing the original Selenium Core implementation and replacing it with one backed by WebDriver. This will affect all users of the Selenium RC APIs. For more information, please see the previous post.

A lot has changed in the 5 years between versions 2 and 3. When we shipped Selenium 2, the Selenium project was responsible for providing the driver for each browser. Now, we are happy to say that all the major browser vendors ship their own implementations (Apple, Google, Microsoft, and Mozilla). Because the browser vendors know their browsers better than anyone, their WebDriver implementations can be tightly coupled to the browser, leading to a better testing experience for you.

The other notable change has been that there is now a W3C specification for browser automation, based on the Open Source WebDriver. This has yet to reach “recommendation” status, but the people working on it (including members of the Selenium project!) are now focusing on finishing the text and writing the implementations.

Mozilla has been a front-runner in implementing the W3C WebDriver protocol. On the plus side, this has exposed problems with the spec as it has evolved, but it also means that Firefox support is hard to track as their engineering efforts have been forward looking, rather than on supporting the current wire protocol used by Selenium WebDriver. For now, the best advice we can offer is for you to try the latest release of geckodriver and Selenium together.

These are exciting times for browser automation! Selenium 3.0 is a major release and we’re looking forward to improving things further, as well as tracking the ongoing work of the W3C spec. Our goal is to keep the changes your tests need to deal with to an absolute minimum, to continue preserving the hard work that’s gone into writing your existing tests.

As a personal note, I’d like to say thank you to each of the many people that have worked so hard to make Selenium 3 possible. That’s not just the developers and contributors to the Open Source project (past and present), but also the engineers from Google, Microsoft, Mozilla, and Apple, and everyone involved with the W3C spec. I’d also like to say thank you to everyone who’s taken the time to report bugs, our users and our community. The project is great fun to work on and you’re the reason for that. A final thank you is due to the Software Freedom Conservancy, who have provided invaluable help with the logistics of running a large OSS project.

Happy hacking, everyone! May your tests run fast and true!

Blog: Selenium 3 is Coming

Tue, 04 Oct 2016 00:00:00 +0000

Selenium 3 is coming! As I write this, we think that “beta 4” will be the last beta before the official 3.0 release. I’m here to tell you about what’s changed, and what impact this will have on your testing.

TL;DR:

WebDriver users will just find bug fixes and a drop-in replacement for 2.x.
Selenium Grid users will also find bug fixes and a simple update.
The WebDriver APIs are now the only APIs actively supported by the Selenium project.
The Selenium RC APIs have been moved to a “legacy” package.
The original code powering Selenium RC has been replaced with something backed by WebDriver, which is also contained in the “legacy” package.
By a quirk of timing, Mozilla have made changes to Firefox that mean that from Firefox 48 you must use their geckodriver to use that browser, regardless of whether you’re using Selenium 2 or 3.

In more depth:

When we released Selenium 2.0 in 2011, we introduced the new WebDriver APIs, and encouraged everyone to start moving to them. If you’re using the WebDriver APIs, then Selenium 3.0 is a simple drop-in upgrade. We’ve not changed any of the public WebDriver APIs, and the code is essentially the same as the last 2.x release. If you’re using Selenium Grid, the same applies: in most cases, you can just drop in the new JAR (or update your maven dependency to 3.0.0), and you’re done.

If the update to Selenium 3 is such a non-event, why did we call this Selenium 3.0? To answer this question, I first need to provide some history, and tell you a little about how Selenium works under the hood. The very first version of Selenium was “just” a very complicated Javascript framework, running in the browser and interpreting the table-based tests you may be familiar with if you use Selenium IDE. We call this “Selenium Core”. This Javascript framework formed the basis of the original implementation of Selenium RC (the oldest set of Selenium APIs, where all the method and functions were on the “Selenium” interface, and which have been deprecated for some time now). Over time, the needs of modern web testing have grown ever more complicated and sophisticated, and Selenium Core is now less capable of meeting these needs than it was before.

With Selenium 3.0, we are deleting the original Selenium Core implementation. If you use the old RC interfaces, we provide an alternative implementation that’s backed by WebDriver. This is the same “webdriver-backed selenium” that has been available as part of Selenium 2 since its release. Because the underlying technology has changed from Selenium Core to WebDriver, you may find some places where your existing tests using RC run into issues. Our experience with migrating suites is that it’s normally a systemic issue that can be fixed with a minimal engineering effort (that is, the problem is normally isolated to a few places, and these can be rewritten to avoid problems)

We’re also removing the original Selenium RC APIs from the main downloads. If you’re a Java user, and need to use them to support existing tests, then you’ll need a dependency to “org.seleniumhq.selenium:selenium-leg-rc:3.0.0” (or later!). It’s strongly recommended that you do not do this unless you absolutely need to.
If you’re someone who runs tests exported from IDE in the table format, there is now a new test runner that the project has made available for you to use that can be downloaded from the project’s website. It takes the same arguments as the old runner, and we’ve done our best to ensure the output of tests remains the same too.

At the same time as the Selenium project is shipping Selenium 3.0, Mozilla are changing the internals of Firefox in a way that makes it more stable and secure, but which also makes the community provided Firefox Driver no longer work. As such, if you use Firefox for your testing, you’ll need to use the geckodriver, which is an executable similar to the chromedriver and the Microsoft WebDriver for Edge. You’ll need to start using geckodriver even if you’re using Selenium 2 — the change is in the browser, not Selenium. Please be aware that geckodriver is alpha software, based on the evolving W3C WebDriver standard: everyone’s working flat out to give you the best testing experience they can, but there are undoubtedly some bumps in the road when it comes to testing with Firefox.

This release marks the culmination of a lot of hard work by the Selenium committers and community. I’d like to thank everyone who has been part of this process, and the Selenium users around the world who have done so much to make the project as successful as it is.

Blog: Announcing Selenium 3.0-beta1

Fri, 29 Jul 2016 00:00:00 +0000

At SeleniumConf in 2013, we announced that a new major version of Selenium would be released “by Christmas”. Fortunately, we never said which Christmas, as it has taken us a while to make all the changes we wanted to make! We’re excited to announce the release of the first beta — Selenium 3.0.0-beta1.

We’d love you to try it out on your projects, and provide us with feedback on where the rough edges are before we ship the 3.0 itself! Please remember that this is a beta release, so your feedback is incredibly helpful and valuable in order to help us smooth any rough edges.

For the last six years we’ve been advising users to switch to the newer WebDriver APIs and to stop using the original RC APIs. With Selenium 3.0, the original implementation of RC has been removed, replaced by one that sits on top of WebDriver. For many users, this change will go completely unnoticed, as they’re no longer using the RC APIs. For those of you who still are, we’ve done our best to make the change as smooth as possible, but we welcome high quality bug reports to help us fix any problems that occur. Maven users will need to add a dependency on the new “leg-rc” package to access the old RC APIs.

There are some other changes that you might need to be aware of:

You’ll need to be running Java 8 to use the Java pieces of Selenium. This is the oldest version of Java officially supported by Oracle, so hopefully you’re using it already!
Support for Firefox is via Mozilla’s geckodriver.
Support for Safari is provided on macOS (Sierra or later) via Apple’s own safaridriver.
Support for Edge is provided by MS through their webdriver server.
Only versions 9 or above of IE are supported. Earlier versions may work, but are no longer supported as MS no longer supports them.

We’ll be posting more information about Selenium 3.0 to this blog soon, but until then if you’re interested in learning more then a recent webinar by Simon is a great place to start.

Blog: Announcing Selenium 2.26: the “It’s Really Real” Release

Fri, 02 Nov 2012 00:00:00 +0000

It’s been a long time since we announced a new Selenium release on this blog, as we moved to a model of quicker releases, but we’ve been working on 2.26 for far longer than normal — it’s out! Download it now! — so I thought it best to let you know. We’re aiming to head back to faster releases, so hopefully you won’t see another blog post about the release for a while (though I’m sure they’ll appear in the “Smatterings of Selenium” posts)

Some highlights that you might be interested in, include support for the latest and greatest versions of the popular browsers out there (including native events on Firefox 16!), the deletion of deprecated methods from the language bindings, better emulation of user input on IE when dealing with “sucker fish” style menus, and a slew of bug fixes. There’s more in the changelog!

The inimitable Jim Evans held the Release Bacon for what has become one of our most challenging releases to do, so a big “thank you!” to him. A “thank you”, also, to the rest of the core developers and Sauce Labs team members who worked on fixing so many bugs and getting our continuous build green, especially Alexei Barantsev who did some amazingly detailed and painstaking work to help the release through. And a final “thank you” to our users: thanks for your feedback and support. 🙂

Blog: Announcing Selenium 2.22

Tue, 29 May 2012 00:00:00 +0000

It’s been a while since the last Selenium release, but I’m happy to announce that Selenium 2.22 is now available for download. This is a big release for us and features two major changes.

The first is that Selenium 2.22 is the first version that requires Java 6 in order to run. This has been the case for the Selenium Server for some time, but this is the first time the client code has required Java 6. Since Java 5 was “end of lifed” in 2009, we don’t expect this to impact many users.

The second major change is that we are now providing a standalone IE server for use with the WebDriver API, similar to the one used by the chrome driver. You can get it from the normal download page. This will allow us to update our IE support independently of the rest of the library (again, mirroring how Chrome is supported) For now, there’s a legacy fallback mode you can use that’ll use the same DLL we’ve always used which can be activated by setting the DesiredCapability “useLegacyInternalServer” to boolean “true” when requesting your IE Driver instance.

Of course, as well as these major changes, there’s the usual host of updates and improvements. We’re continuing to refine the new SafariDriver, and we’re happy to announce native events for Firefox 12. You can check out the other updates in the CHANGELOG.

Blog: Announcing Selenium 2.19: the Prancing Unicorn release

Wed, 08 Feb 2012 00:00:00 +0000

You might be pleased to hear that Selenium 2.19 has been released (download it from here!). There’s one big user facing changing that we’d like to tell you about: the webdriver-backed selenium can now be used in supported languages.

By providing this capability, it’s possible to migrate from RC to the WebDriver APIs without rewriting all your tests in one fell swoop (which must be a Good Thing, right?) An example of how to use it in Python would be:

driver = RemoteWebDriver(desired_capabilities = DesiredCapabilities.FIREFOX)
selenium = DefaultSelenium('localhost', 4444', '*webdriver', 'http://www.google.com')
selenium.start(driver = driver)

Provided you keep a reference to the original webdriver and selenium objects you created you can use the two APIs interchangeably. You’ll see that the magic is the “*webdriver” browser name passed to the selenium instance, and that we pass the webdriver instance when calling start().

We hope you like it!

PS: I have no idea why this is the Prancing Unicorn release, but it’s been a while since we named one 🙂

Blog: Selenium 2.16 Released: Welcome to 2012!

Thu, 05 Jan 2012 00:00:00 +0000

It’s been a while since we last blogged about a Selenium release. Since the release of 2.0, we’ve been attempting to give you a fresh and shiny Selenium release every week (though, in reality, we’re managing to get you one every 10 days on average). This allows you to pick the version that’s most suitable for you and your teams, but provides a route for quick feedback on how we’re doing. I think we’ve now ironed out a lot of the initial problems and bumps we ran into, so we are extremely proud to announce the release of Selenium 2.16.

If you’re unsure about what’s been happening since the last time we announced a release here, the best place to look is our changelog. The most notable feature in 2.16 is better support for Firefox 9, but if it’s been a while since you’ve last updated, we’ve been beavering away on bug fixes and making existing features work as flawlessly as possible. Now’s a great time to update!

One of the key tools we use for assessing whether it’s okay to push a release is our continuous build. This watches for each and every change made to the project’s source code, and runs an increasingly vast suite of tests to verify that nothing has broken. Our friends at Sauce Labs have been extremely generous in providing support for this, and have worked closely with us to make the build as stable and quick as possible. Special kudos and thanks to them!

Blog: Selenium 2.9 Released

Thu, 20 Oct 2011 00:00:00 +0000

We’re pleased to announce the release of Selenium 2.9. As well as improving the stability of Grid under high loads, we’ve added an experimental (and temporary!) feature that allows the Firefox driver to use a different mechanism for determining when a page is loaded. This is designed to handle the case where the driver appears to hang, as it’s waiting for all incoming requests to complete before continuing. How to enable this mode is listed in the changelog.

This release also includes an updated Android driver, allowing your tests to run on Ice Cream Sandwich devices.

Blog: Selenium 2.8 Released

Thu, 06 Oct 2011 00:00:00 +0000

In keeping with our (roughly) weekly releases, Selenium 2.8 was released today (and on Maven too), with a *huge* list of bug-fixes! As well as improved stability, if you’re using the Java API, this release adds the ability to upload files to a RemoteWebDriver server (see RemoteWebDriver.setFileDetector).

Particular thanks have to go out to our two newest committers, Alexei Barancev and Ajay Kemparaj, for the copious bug-fixes they’ve contributed!

We’re already hard at work getting 2.9 ready for next week with even more more bug-fixes – watch this space!

Blog: Selenium 2.6 Released

Fri, 16 Sep 2011 00:00:00 +0000

If you’ve been watching this blog carefully you’ll have noticed that the last release announcement we made was for 2.3, so it may come as a surprise that we’re announcing that 2.6 has been released (even on Maven!). Don’t worry: 2.4 and 2.5 were released on time and without muss or fuss. 2.6, on the other hand has been almost three weeks brewing.

Selenium 2.6 introduces a raft of improvements and stability fixes. Kristian Rosenvold has been working wonders on Grid 2.0, addressing many reported issues and cleaning up the implementation. In the finest tradition of the project, I now owe him a dinner for his hard work. Thank you, Kristian!

For those of you not using Grid, as well as the normal suite of bug fixes, Selenium 2.6 now supports all versions of Firefox from 3.0 up to 7. For those of you using Java, there is an ExpectedConditions class that supplies many useful criteria when using the Wait and WebDriverWait classes. The packaged version of the OperaDriver has also been bumped to 0.7.2, which works hand-in-hand with Opera 11.5 and above.

We’ve also spent a considerable amount of time and effort working out the kinks in the Advanced User Interactions API. We’d love to hear how you’re using it, and what the gaps are that you can see. For more details about what’s changed, have a look at the release notes.

The release frequency has dropped recently, but we’re planning to head back to weekly releases from here on in. 2.7 is just around the corner!

Blog: Selenium 2.3 Released

Tue, 02 Aug 2011 00:00:00 +0000

Continuing our new tradition of weekly releases, we’re very pleased to announce the release of Selenium 2.3. The release notes for this version are pretty slim:

Better detection of clickable areas in Firefox.
Merge of Google-contributed code into the underlying javascript libraries used by the drivers.

We’ve also fixed bugs, one of which was being a nuisance for users of IBM’s JRE. The complete changelog can be found in the zipped downloads or in our source tree.

If you’re a Chrome user, then it’s a great idea to head over to the Chromium project’s download page to pick up the executable used by the ChromeDriver. It’s recently been updated, and now includes support for handling alerts and prompts! Thanks, Google!

Blog: Selenium 2.2 Released

Tue, 26 Jul 2011 00:00:00 +0000

The feedback from the last release was heard loud and clear: little and often it is!

We’re proud to announce the release of Selenium 2.2. What’s new this time? For many users, this is simply a bug fix release as there are no new major features. One thing you might appreciate is better exceptions being thrown when xpath searches return something other than a web element when using the WebDriver APIs, and we’re continuing to tweak the emulation of user events.

If you’re a .Net user, there is now an official NuGet package, and if you’re a maven user then rest assured the release is heading to the central repo as quickly as we can manage.

Blog: Selenium 2.1 Released

Mon, 18 Jul 2011 00:00:00 +0000

Now that Selenium 2 has been released, one of the goals of the project is to provide regular updates to our users and the community. The aim is for these updates to be small and manageable, incrementally addressing issues and problems raised by you. Selenium 2.1, which is launched today, marks the first of these regular, small releases.

Selenium 2.1 is largely focused on improving Grid with a host of minor improvements including better tracking of “orphaned” browser instances. There are also some bug fixes in the Firefox and IE WebDrivers, particularly when dealing with elements that are just off screen, and in making the Selenium RC emulation in the Java bindings more robust when confronted with pages that haven’t started loading.

As you can see, this is a “bite size” release, but we’d love to know: would you prefer these small, swift releases or larger ones? Please answer in the comments, or on the mailing list!

Blog: Selenium 2.0: Out Now!

Fri, 08 Jul 2011 00:00:00 +0000

We are very, very pleased to announce the release of Selenium 2.0. If you’ve been waiting for a stable release since 1.0.3, now’s the chance to update. And if you do, what will you find?

For users of Selenium 1, this is a drop-in replacement. You’ll find support for modern browsers such as Firefox 5 and IE 9, as well as a wealth of bug fixes and stability improvements. That’s one reason to update, but what other reasons are there?

The big feature of this release — and the reason for the new version number — are the new WebDriver APIs for Python, Ruby, Java and C#. These have been in development for over four years, and are already widely used, trusted and depended on. The WebDriver APIs have been written by developers familiar with each language, so they feel like they belong there. We’re very proud of them, and hope you enjoy using them.

Support for WebDriver is also baked into Opera and Chrome, and we’re working closely with Mozilla to ensure that their browsers also support it. Looking to the future, WebDriver also works on both Android and iPhone, allowing you to test your sites on the next wave of the Web.

As well as support by the browser vendors, WebDriver also provides excellent emulation of user inputs using something we call “native events”. Normal browser automation frameworks, including older versions of Selenium, simulate user interactions via the Javascript engine of the browser. This approach is error prone as each browser has its own quirks. “Native events” are fired at the OS level instead, avoiding a large amount of browser-specific complexity.

Advanced Selenium users will be pleased to hear that the standalone selenium server also includes support for distributed testing via Selenium Grid. This new Grid implementation supports testing using both the original Selenium API and WebDriver, and has been developed as a collaboration between the current Grid maintainer and an engineer from eBay.

We’re working hard to ensure that Selenium IDE also supports all these new features and APIs. IDE version 1.1.0 should be released next week, with support for exporting to the four main languages supported by WebDriver. Please keep an eye on this blog for announcements! There will also be follow up posts, exploring and explaining each of the new features, and providing you with more information.

Of course, Selenium 2.0 is a major milestone, but we’re not done yet. This release marks the point where we expect our APIs to change very little from now on and where we believe it’s a solid release. Like all software, it has niggles and bugs, and we’ll be focusing on addressing these as your feedback comes in.

As a personal note, I’d like to say thank you to each of the many people that have worked so hard to make this the best Selenium version yet. Not only the developers but also the team working on making our documentation clear and easy to read, everyone who’s taken the time to report bugs, and also to you; our users and community. The project is great fun to work on, and you’re the reason for that. Thank you!

Blog: New ChromeDriver

Thu, 07 Jul 2011 00:00:00 +0000

The ChromeDriver is composed of two major pieces. There are the client APIs, which you use in your tests, and there’s a server part, which the client APIs know how to start and run and which takes the form of an executable called “chromedriver”. The server piece is maintained by the Chromium team, and they’ve just released a new version, with support for Chrome 14 and with bug fixes. If you’re using Selenium 2.0rc3 and you’re also using the ChromeDriver, head over to the Chromium project’s download page for the latest and greatest!

Blog: Selenium IDE 1.0.12 – now with Firefox 5 support

Mon, 04 Jul 2011 00:00:00 +0000

Last week we quietly released Selenium IDE 1.0.12 on the website. It has Firefox 5 support along with other improvements. See the release notes and unofficial announcement. Download it here or ask Firefox to check for plugins updates.

And for those who did not download 1.0.11 (it was not pushed through the update system) you will want to read about the formatter change that landed.

Blog: Selenium 2.0rc3: The “Next One’s The Big One” Release

Mon, 27 Jun 2011 00:00:00 +0000

When we pushed the 2.0rc1 live, we really hoped that the next release would be 2.0 final. We very quickly got some feedback that encouraged us to push a 2.0rc2. Now, after just under three weeks, we’re launching a third and final release candidate. You can download it from the Selenium HQ site or directly from Google Code.

We think we’ve addressed many of the common issues, added some polish and added a host of bug fixes and minor changes, and we hope to hear your feedback! The following headline changes have been made in Selenium 2rc3:

The deprecated RenderedWebElement interface has now been removed. Most of the functionality has been moved to either WebElement or to the Actions class.
The deprecated WebElement.getValue() method has been removed. Use WebElement.getAttribute(“value”) instead.
After some debate in the team, “WebElement.setSelected” and “WebElement.toggle” have been deprecated. They will be removed in the final release.
Thanks to the hard work of Mozilla engineers, we now offer Firefox 5 support.
The Opera driver, developed by the lovely chaps at Opera Software, is bundled with this release.
Improvements in the way that mouse interactions are simulated, particularly when elements are outside the visible area of the page.

As with almost all releases, there are still some issues left to resolve, but we’re working hard to make Selenium 2.0 as good as it can be.

Blog: Selenium 2.0rc2: The Better Working Release

Thu, 02 Jun 2011 00:00:00 +0000

You win some and you lose some. We’d been really pleased to get Selenium 2.0rc1 out, so we were pretty disappointed to hear that some of you were running into problems with the Java version of the IE driver not launching IE sometimes. That’s definitely not good, so we fixed the problems and have released Selenium 2.0rc2. It’s the same as rc1, but with fewer problems 🙂

We’re still very keen to hear your feedback! Let us know what you think!

Blog: Selenium 2.0rc1: The Grid Release

Wed, 01 Jun 2011 00:00:00 +0000

We’re very happy to announce the first Release Candidate for Selenium 2, available for Java, C#, Ruby and Python. The API has been stabilised and the functionality needed for the final 2.0 release is mostly in. We’re going to be working hard to get there as soon as possible, but now’s the perfect time to test the waters and provide us with any feedback you may have! Grab the downloads from the site!

Highlights:

Grid 2: A major feature of this release is Grid 2, an implementation of the Selenium Grid that supports WebDriver’s wire protocol, allowing tests using Selenium WebDriver to be distributed through it. There are some docs to help you get started on the wiki.
New ChromeDriver: Following a complete rewrite of the ChromeDriver, Selenium 2 is now supported natively by the Chrome browser itself. In order to use this, you must download the chromedriver executable from the Selenium project site.
OperaDriver support: We’ve bundled the most excellent OperaDriver into the release to make it easy to get started testing with Opera.
Support for native events in Firefox 4.
Advanced User Interactions: An API that allows you to model complex user interactions, such as clicking on an element, holding the shift key, clicking on three more, and then dragging the four elements to a final destination. The entry point to this API is the Actions class.

We’ve also deleted all methods that were deprecated in 2.0b3 and have marked a number of methods and classes (notably RenderedWebElement and WebElement.getValue) deprecated. These will be deleted in the next release.

Known issues:

Native events on Linux may not work properly on tests that include alerts and prompts.
Mouse actions using the Advanced User Interactions API may not work properly for elements that have to be scrolled into view.

We plan on making our releases more frequent in the run up to 2.0final and polish off the bugs and issues. Stay tuned! This is going to be fun 🙂

Blog: Selenium IDE 1.0.11 – Now with Firefox 4 Support!

Mon, 30 May 2011 00:00:00 +0000

We know that you have been waiting eagerly for this release and you have to wait no more. Selenium IDE 1.0.11 is now here and you can get it from the seleniumhq download site. The update will also be pushed to you automatically over the next couple days.

Other things of note around this release
•Release Notes
•Where to log bugs
•Welcome Selenium IDE 1.0.11 (with Firefox 4 support)

Blog: Selenium 2.0b3: The Next Gen Browser Release

Mon, 21 Mar 2011 00:00:00 +0000

It’s been about 5 weeks since the release of beta 2, so we’re very pleased to announce that Selenium 2.0b3 has just been released simultaneously for Java, .Net, Ruby and Python. You can download it from Selenium HQ or from the Google Code site. This release focused on providing excellent support for the next generation of browsers, particularly IE 9 and Firefox 4, and we think you’ll like what you’ll find.

Restructured documentation at Selenium HQ
An improved user interaction API
- Including experimental IME support on Windows.
Alerts and prompts handling for IE.
Marked the following APIs as obsolete in .Net:
- IRenderedWebElement.Hover()
- IOptions.Speed
Even more improvements to the Java webdriver-backed selenium
- We’ll document the migration path before 2.0b4 is out!
A significantly faster Android Driver

As well as these changes, there’s also the regular clutch of bug fixes and tweaks. For the number crunchers, there were a total of 331 changes that landed in the 5 weeks since the last release, with the 5 most active contributors working on each of the different languages supported by Selenium.

In addition to the enormous thanks that go to the developers, I’d like to add a big thank you to the Mozilla engineers who chipped in on the IRC channel at the last minute to help us work through some issues with Core. We’d not have been able to get this release out when we did without their help. Thank you Mozilla!

The next release will be focused on stabilization work, reducing our bug count and adding support for Grid 2.0.

Blog: Selenium 2.0b2 Released

Tue, 15 Feb 2011 00:00:00 +0000

We’ve just released Selenium 2.0b2. If you’re the impatient sort who loves to have the latest and greatest, head over to the download site and get it while it’s hot. If you’re a Python user, then all you need to do is a simple “pip install -U selenium”. Ruby users can, as ever, simply run “gem install selenium-webdriver”. Maven users need to wait just a little bit longer: we’re going to be checking the release in ASAP.

Between beta 1 and beta 2, we held a week-long Bug Bash, during which we closed a significant number of bugs. From a user’s perspective, other highlights include:

A more stable, capable iPhone driver.
Updated Android driver.
Improved python bindings for Selenium WebDriver. The namespace is now “selenium.webdriver”
Added “Selenium.getCssCount” to mirror “Selenium.getXpathCount”
“WebElement.getText()” performs more consistently across different browsers.
Mono users can use the .Net bindings
Continued to improve the WebDriverBackedSelenium. If you’re looking to migrate from Selenium 1 to Selenium 2, and want to take your time, this is a useful stepping stone.
Reworked the Advanced User Interactions APIs. The big change is that the WebDriver APIs no longer rely on classes from the AWT.
.Net users now have more support classes, to make writing tests less tiresome.
The remote webdriver makes better use of sockets, which improves stability and scalability on Windows.
Started to add support for driving multiple IE instances. This is considered experimental, but we’d love to hear it’s working for you!

If you’re interested in the guts of Selenium 2 and how it worked, then you might find these interesting:

Continued reworking the IE and iPhone drivers to use the Automation Atoms.
Reworked the structure of the source tree to be more language focused.
We have the skeleton of a webdriver-backed selenium for Python.

As you can see, this is a big release. Beta 3 should be out a lot more quickly, and will be focusing on improving support for IE 9 and Firefox 4. Over the course of the 2.0b3 development, we shall also be removing as many deprecated methods as possible, so be sure to remove deprecation warnings from your builds when using 2.0b2!

Blog: OperaDriver Released

Wed, 09 Feb 2011 00:00:00 +0000

I think the word that I’m looking for is “wow”. Perhaps “Wow!” would express the concept a little more clearly. Perhaps “WOW!” would be even clearer. Yes, definitely. “WOW!” is a good way of describing this.

Before Christmas, Opera Software announced a pre-release of OperaWatir, an implementation of the Watir 2 API. What you may not know is that Watir 2 rests on the same WebDriver core as Selenium 2. Today, Opera made the source of the OperaDriver available on github: https://github.com/operasoftware/operadriver

This is “WOW!” It’s the first time a browser manufacturer has released their own implementation of the WebDriver APIs, and it shows how much Opera values test automation. Selenium 2 users now have an easy way to test that their sites work with Opera.

What are you waiting for? Go! Download! Test!

Selenium – releases

Blog: Selenium 4.18 Released!

Highlights

Noteworthy changes per language

Contributors

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

Blog: Selenium 4.17 Released!

Highlights

Noteworthy changes per language

Contributors

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

Blog: Selenium 4.16 Released!

Highlights

Noteworthy changes per language

Contributors

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

SELENIUM_CI_TOKEN not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set

`SELENIUM_CI_TOKEN` not set