This is the multi-page printable view of this section. Click here to print.
Blog Posts - 2024
- HtmlUnit Remote: Acquiring Remote HtmlUnitDriver Session in Selenium 4 Grid
- Two Chrome features you should disable
- Welcoming Puppeteer to the WebDriver World
- Protecting unsecured Selenium Grids against SeleniumGreed
- Selenium 4.23 Released!
- Sauce Labs: A New Milestone with Selenium
- Celebrating a Milestone: BrowserStack Becomes Selenium's Development Partner
- Selenium 4.22 Released!
- Multi-Arch Images via Docker Selenium
- Selenium 4.21 Released!
- Selenium 4.20 Released!
- Selenium 4.19 Released!
- Update imports to use BiDi Java
- Selenium 4.18 Released!
- Selenium 4.17 Released!
- Selenium Vs … blog posts
HtmlUnit Remote: Acquiring Remote HtmlUnitDriver Session in Selenium 4 Grid
HTMLUNIT REMOTE
The HtmlUnit Remote project implements a W3C WebDriver protocol wrapper for HtmlUnitDriver, which enables Selenium 4 Grid to supply remote sessions of this headless browser.
Background
To eliminate behavioral differences between local and remote configurations, the Selenium Foundation framework always acquires browser sessions from a Grid instance, managing its own local grid instance when not configured to use an existing grid. Selenium 3 Grid could be configured to supply HtmlUnitDriver sessions, supported by special-case handling within the Node server itself. This handling was not carried over into Selenium 4 Grid, which was completely re-engineered with new architecture and vastly expanded capabilities.
The lack of HtmlUnitDriver support in Selenium 4 Grid necessitated reconfiguring the Selenium Foundation project unit tests from using this Java-only managed artifact to using a standard browser like Chrome, an external dependency that requires additional resources and imposes additional risks of failure.
The driver service implemented by HtmlUnit Remote enables Selenium 4 Grid to supply HtmlUnitDriver sessions.
Project Rationale
My initial objective for creating HtmlUnit Remote was to retain feature parity in Selenium Foundation for the set of browsers supported with Selenium 3 and Selenium 4. Although I could configure my unit tests to target a conventional browser, I also wanted to avoid additional external dependencies with associated risks.
Once I began investigating the features and functionality I would need to enable Selenium 4 Grid to supply HtmlUnitDriver sessions, I recognized an additional benefit this project could provide - comprehensive standardized configurability.
HtmlUnitDriver Configuration
All remote drivers are configured via a standard Selenium feature - the Capabilities object. Prior to the HtmlUnit Remote project, many of the options of HtmlUnit could not be accessed or modified via the Capabilities API. These were only available via custom HtmlUnitDriver methods, and the way that non-standard capabilities had been added to the Capabilities object didn’t conform to the W3C specification.
This meant that the initial phase of the HtmlUnit Remote project was to implement a comprehensive W3C-compliant configuration object - the HtmlUnitDriverOptions class. This class extends AbstractDriverOptions, adding driver-specific capabilities under an extension named garg:htmlunitOptions
. Support for this class provides full configurability of all HtmlUnitDriver options through the standard Capabilities API.
This standardized configuration API has been incorporated directly into HtmlUnitDriver, providing the core implementation for manipulating every driver setting. To maintain backward compatibility, all of the existing constructors and configuration methods have been retained, reimplemented to use this new core API.
W3C Remote Protocol Wrapper
With full standardized configurability in place, the next step was to create a server that implements the W3C WebDriver protocol. The HtmlUnitDriverServer functions as a remote protocol wrapper around one or more HtmlUnitDriver sessions, performing the following tasks:
- Create and manage driver sessions
- Route driver commands to specified driver sessions
- Package driver method results into HTTP responses
HtmlUnit Remote Packaging
Rather than bulk up the existing driver with remote-specific features, HtmlUnitDriverServer and associated facilities are packaged in a companion htmlunit-remote
artifact. In addition to the server, this artifact defines a driver information provider (HtmlUnitDriverInfo), a driver service (HtmlUnitDriverService), and a custom slot matcher (HtmlUnitSlotMatcher).
Connecting to the Grid
Next up is HtmlUnitDriverInfo, which specifies the basic characteristics of the driver and provides a method that creates a driver session with specified capabilities. This class implements the standard WebDriverInfo interface.
With availability of HtmlUnitDriver advertised by this information provider, Selenium 4 Grid nodes can be configured to provide driver sessions:
htmlunit.toml
[node]
detect-drivers = false
[[node.driver-configuration]]
display-name = "HtmlUnit"
stereotype = "{\"browserName\": \"htmlunit\"}"
[distributor]
slot-matcher = "org.openqa.selenium.htmlunit.remote.HtmlUnitSlotMatcher"
The selenium-server
JAR doesn’t include the HtmlUnitDriver artifacts; these need to be specified as extensions to the grid class path via the --ext
option:
java -jar selenium-server-<version>.jar --ext htmlunit-remote-<version>-grid-extension.jar standalone --config htmlunit.toml
The grid-extension
artifact provides all of the specifications and service providers required to enable Selenium 4 Grid to supply remote sessions of HtmlUnitDriver. This artifact combines htmlunit-remote
with htmlunit3-driver
, htmlunit
, and all of their unique dependencies.
Implementation Details
HtmlUnit Remote provides the following elements:
- HtmlUnitDriverInfo - This class informs Selenium 4 Grid that HtmlUnitDriver is available and provides a method to create new driver instances.
- HtmlUnitSlotMatcher - This custom slot matcher extends DefaultSlotMatcher, indicating a match if both the slot stereotype and requested browser capabilities specify
htmlunit
as the browser name. - HtmlUnitDriverService - This class manages a server that hosts instances of HtmlUnitDriver.
- HtmlUnitDriverServer - This is the server class that hosts HtmlUnitDriver instances, enabling remote operation via the W3C WebDriver protocol.
In operation, HtmlUnitDriverService is instantiated by Selenium 4 Grid node servers that are configured to support HtmlUnitDriver. Unlike other driver services, which launch a new process for each created driver session, HtmlUnitDriverService starts a single in-process server that hosts all of the driver sessions it creates.
This is a guest blog post by Scott Babcock
Two Chrome features you should disable
Search engine selection screen
Starting with version 127 of Chrome, the browser now asks which search engine you would like to use, which is great for regular users.
But for automation, it does so every single time.
To bypass this, use the argument below when specifying the browser options.
--disable-search-engine-choice-screen
Chrome wastes over 60MB of your bandwidth downloading language plugins
The second feature is something that has been with Chrome for quite a while now.
Every time you launch Chrome, it will query and download several .crx files.
These files can even be left over on your disk’s download folder if you create and close drivers faster than these can be processed.
To disable this feature, use the browser option below.
--disable-features=OptimizationGuideModelDownloading,OptimizationHintsFetching,OptimizationTargetPrediction,OptimizationHints
This is a guest blog post by Marek Andreansky
Welcoming Puppeteer to the WebDriver World
The Selenium Project has always been fully supportive of creating a standard to improve the quality of the web that we use. We started with the WebDriver Specification and over the last couple of years have been working with the Safari, Edge, Chrome, and Firefox teams on the WebDriver-BiDi specification.
Today, we are celebrating that Puppeteer has moved over to using WebDriver-BiDi, the new WebDriver Specification that allows WebDriver clients to have event driven APIs instead of the synchronous way Selenium has done it before.
This new protocol allows us to be able to do things Selenium always wanted to do but was never surfaced to us in a meaningful way. We have documented all the latest additions to Selenium, thanks to WebDriver-BiDi, in our documentation
You can read about the latest changes on Mozilla Hacks and on the Chrome Developer Blog.
Congratulations to everyone in making this a reality and supporting a standardised web!
Protecting unsecured Selenium Grids against SeleniumGreed
Over the last week there have been stories going around about crypto miners abusing unsecured Selenium Grids by injecting code in the session create to download and start up crypto miners. This came out thanks to the work from Wiz about an attack they have called SeleniumGreed. This issue can be abused on most versions of Selenium but there appears to be a lot of effort going into abusing Selenium Grid 3.14. Please upgrade as some of the security items have been added since then.
Selenium Grid by default doesn’t have any authentication as the assumption has always been that we want you to put this behind a secure network to prevent people from abusing your resources. There are ways that you can secure the grid, and we have documentation available on how to do this in our help section. You can see more details if you run
java -jar selenium-server-<version>.jar info security
Another way to combat this is to use a cloud provider to run your Selenium Grid. We have numerous vendors that sponsor us so have a look at our sponsors page. If you need help, after reading the help section please come into our chat rooms and we will try guide you through making your grid more secure.
Selenium 4.23 Released!
We’re very happy to announce the release of Selenium 4.23.0 for Javascript, Ruby, Python, .NET, Java and the Grid! Links to everything can be found on our downloads page.
Noteworthy changes per language
- Java
- Add custom duration for Actions constructor (#14085).
- Set session-request-timeout as client readTimeout in RemoteNewSessionQueue.
- Add high-level BiDi logging APIs.
- See all changes
- JavaScript
- Add source type to BiDi log entry.
- Add high-level script pinning BiDi APIs.
- See all changes
- .NET
- Log http requests/responses via internal DiagnosticsHttpHandler.
- Return protected synchronous Execute method in WebDriver.
- See all changes
- Python
- Allow RelativeBy to take 2 parameters.
- See all changes
- Ruby
- Improved error messaging.
- See all changes
Contributors
Special shout-out to everyone who helped the Selenium Team get this release out!
Selenium
Viet Nguyen Duc
Agustin Pequeno
Alex
Selenium Docs & Website
ian zhang
Agustin Pequeno
Pallavi
Docker Selenium
Viet Nguyen Duc
Werner Robitza
Sebastian Schreck
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
David Burns
Boni García
Diego Molina
Sri Harsha
Nikolay Borisenko
Alex Rodionov
Puja Jagani
Simon Stewart
Titus Fortner
Stay tuned for updates by following SeleniumHQ on X (Formerly Twitter) or LinkedIn!
Happy automating!
Sauce Labs: A New Milestone with Selenium
Selenium has witnessed an exceptional year filled with expansion and progress. The rising popularity of Selenium’s Python Bindings is prominently showcased through the engaging discussions at the Selenium Conference and on LinkedIn. Concurrently, the Java bindings have reached a significant landmark, surpassing 100 million downloads. In addition to this, the community has managed to garner over 2.5 million active Selenium users monthly.
We could not have achieved Selenium’s 20th anniversary without the collective efforts of numerous volunteers and the invaluable assistance of a company like Sauce Labs.
In 2008, Jason Huggins, Selenium’s creator, established Sauce Labs, a company that has since played a crucial role in Selenium’s expansion.
Sauce Labs has provided a platform for the Selenium Project to display its accomplishments, including various keynotes at SauceCon. Here, figures like Simon Stewart and Jim Evans have been able to share their visions for the future of Selenium.
Financially, Sauce Labs has substantially supported the Selenium Project, sponsoring both the project itself and the Selenium Conference over many years. This backing has been instrumental in allowing the project to flourish.
Selenium thrives on collaboration, and Sauce Labs has been a vital facilitator. They have enabled the Selenium Project to host in-person events like the Test Automation Summit in Berlin in 2022. These gatherings have provided opportunities for members of the Selenium Project to engage with creators of different testing frameworks, fostering discussions on ecosystem improvements. Sauce Labs has also hosted Selenium Dev Summits, where the project’s future has been a central topic.
Sauce Labs contributions extend beyond financial support. They have significantly contributed to the technical and organizational well-being of the Selenium Project. Boni Garcia developed the first version of Selenium Manager while at Sauce Labs. Furthermore, several Sauce Labs employees, including Marcus Merrell, Diego Molina, and Titus Fortner, continue contributing to the Selenium project, driven by their passion. This passion is shared by Sauce Labs, enabling these contributions to be part of their daily work.
This unwavering support has nurtured a project governed openly, not by a single entity, but by the community. This model has welcomed diverse contributors, including Google Chrome, Microsoft, Apple, LambdaTest, Applitools, BrowserStack, and Mozilla Firefox teams. Together, they have developed WebDriver BiDi, the next generation of WebDriver.
The project’s open governance and collaborative nature have allowed continuous work on client bindings, particularly WebDriver BiDi, community support, documentation improvements, and maintenance of additional projects.
Sauce Labs has been an unnamed development partner for the Selenium Project for many years. With this in mind, the Selenium Project now shows its appreciation to Sauce Labs for their years of continued support by creating a new sponsorship tier called the Development Partner and naming Sauce Labs the first and official Development Partner.
Sauce Labs has Selenium in its DNA, and Selenium has Sauce Labs in its DNA. This partnership celebrates their shared history and future. We are excited to see what the future holds for both Selenium and Sauce Labs, and we are excited to continue to work together for the next twenty years.
If you want to learn more about this partnership and win a limited edition t-shirt, check How Did Sauce Labs Get Its Name? A Selenium Story.
Celebrating a Milestone: BrowserStack Becomes Selenium's Development Partner
It has been a great year for the Selenium community as it continues to grow. The popularity of Selenium’s Python Bindings is evident from the discussions at the Selenium Conference and on LinkedIn, while the Java bindings have impressively surpassed 100 million downloads.
This project, having reached 20 years old this year, would not be possible without the amazing contributions from our volunteer contributors and the Open Source Program Offices of companies like BrowserStack that allow us to work on this project as part of our day jobs.
About BrowserStack They have over 50,000 organizations and 6M users using their end-to-end testing platform. BrowserStack has been one of the Selenium project’s biggest supporters for years and currently employs several of Selenium’s core maintainers, donating a significant portion of their time towards the development, maintenance, support, and leadership of open-source Selenium repos.
This dedicated support has allowed us to continue work on the client bindings, especially the work going into WebDriver BiDi, support our community, continuously improve our documentation, and maintain all the extra projects we oversee, ensuring Selenium can continue to thrive for the next 20 years. We are also thrilled to highlight the collaborative efforts between the BrowserStack team, the Google Chrome team, Microsoft, Apple, SauceLabs, and the Firefox team, who have come together to build Selenium WebDriver BiDi, the next generation of Selenium. This collaborative spirit embodies our dedication to enhancing the testing experience for the Selenium user community. With this in mind, the Selenium Project now shows our appreciation to BrowserStack for their years of continued support by creating a new sponsorship tier called the Development Partner. We are deeply indebted to BrowserStack for all their support and are proud to recognize them as our first official Development Partner. This work has allowed us to continue progress on the client bindings, especially the work going into WebDriver BiDi, support our community, continuously improve our documentation, and maintain all the extra projects we oversee, so Selenium can continue to be around for the next 20 years!
Selenium 4.22 Released!
We’re very happy to announce the release of Selenium 4.22.0 for Javascript, Ruby, Python, .NET, Java and the Grid! Links to everything can be found on our downloads page.
Highlights
- Selenium has at least 2.6 active users in the last 30 days. 200k more than last month!
- All information we collect is publicly available.
- The numbers only represent users who have Selenium Manager enabled and are using Selenium v4.17 or greater.
- Python, Chrome and Windows all see the majority of use.
- Chrome DevTools support is now: v124, v125, and v126 (Firefox still uses v85 for all versions)
- The first implementations of the new BiDi API have rolled out in Ruby, Python and JavaScript
Noteworthy changes per language
- Java
- Enabling BiDi can now be accomplished by calling
enableBiDi()
on an Options class instance. - Video file name in Dynamic Grid can be set with
se:videoName
capability. - See all changes
- Enabling BiDi can now be accomplished by calling
- JavaScript
- BiDi API for console logging and JavaScript errors has been implemented.
- Additional BiDi implementations.
- See all changes
- .NET
- The .NET bindings have started to roll out asynchronous methods.
- The synchronous methods will still be supported, but they will call the async methods “under the hood.”
- This release adds asynchronous methods to the Navigation class.
- See all changes
- The .NET bindings have started to roll out asynchronous methods.
- Python
- This release implements a new way of working with Chrome Devtools Protocol
- The previous implementation requires async/await pattern, so it was not backwards compatible.
- The new implementation is backwards compatible and executes async code in separate threads.
- Updated the webkitgtk and wpewebkit driver implementations.
- Enabling BiDi can now be accomplished by setting the
enable_bidi()
property of an Options class instance toTrue
. - BiDi API for console logging and JavaScript errors has been implemented.
- See all changes
- This release implements a new way of working with Chrome Devtools Protocol
- Ruby
- Implemented a toggle for BiDi and Classic implementations.
- BiDi API for console logging and JavaScript errors has been implemented.
- See all changes
- Rust
- Added the ability to stream logging information to stdout instead of after execution complete.
- Improved binary location on Windows with native Rust methods.
- See all changes
Contributors
Special shout-out to everyone who helped the Selenium Team get this release out!
Selenium
Andrei
Viet Nguyen Duc
Agustin Pequeno
Alex
Alexander Millin
Scott Babcock
Vladislav Velichko
James Yuzawa
Selenium Docs & Website
ian zhang
Agustin Pequeno
Joshua Yam
Pallavi
Sang Nguyen
Docker Selenium
Viet Nguyen Duc
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
David Burns
Boni García
Diego Molina
Sri Harsha
Alex Rodionov
Puja Jagani
Simon Stewart
Titus Fortner
Stay tuned for updates by following SeleniumHQ on X (Formerly Twitter) or LinkedIn!
Happy automating!
Multi-Arch Images via Docker Selenium
We’re very happy to announce the landing of Multi-Arch Images for Selenium Grid Server on the Selenium Docker Hub registry!
Motivation
For experimental Docker container images that are able to run on platforms such as the Apple M-series or Raspberry Pi, the community-driven repository initiative hosted at SeleniumHQ-Community/docker-seleniarm. These images are built for separate architectures: linux/arm64 (aarch64), linux/arm/v7 (armhf), and linux/amd64 and published on Seleniarm Docker Hub registry.
In order to bring more awareness to the existence of the Multi-Arch Docker container images, provide more insight and transparency on how the container images are built, as well as overcome challenges in building and maintaining them. We have decided to merge the fork into the main project Docker Selenium and published multi-arch images on Selenium Docker Hub registry.
Overview
From image tag releases 4.21.0
onwards, the architectures
supported by Docker Selenium as below
Architecture | Operating System | Available |
---|---|---|
x86_64 (aka amd64) | Ubuntu LTS | ✅ |
aarch64 (aka arm64/armv8) | Ubuntu LTS | ✅ |
armhf (aka arm32/armv7l) | N/A | ❌ |
Based on the architecture of the host machine, Docker will automatically pull the correct image for the platform.
Browser Binaries
Let’s take a moment to look at the browser binaries which are available for various architectures
Google does not build Chrome (google-chrome) for Linux/ARM platforms. Hence, the Chrome (node and standalone) images are only available for AMD64. Similarly, Microsoft does not build Edge (microsoft-edge) for Linux/ARM platforms.
Instead, the open source Chromium browser is used in place of Chrome and Edge. The standalone-chromium
and node-chromium
$ docker run --rm -it -p 4444:4444 -p 5900:5900 -p 7900:7900 --shm-size 2g selenium/standalone-chromium:latest
Mozilla Firefox now is available for Linux/ARM64 via Nightly channel. The Firefox version in the ARM64 image will be different from the AMD64 version until the stable release is available.
Image Name | Operating System | amd64 | arm64 |
---|---|---|---|
standalone-chromium | Ubuntu LTS | ✅ | ✅ |
node-chromium | Ubuntu LTS | ✅ | ✅ |
standalone-firefox | Ubuntu LTS | ✅ | ✅ |
node-firefox | Ubuntu LTS | ✅ | ✅ |
standalone-edge | Ubuntu LTS | ✅ | ❌ |
node-edge | Ubuntu LTS | ✅ | ❌ |
standalone-chrome | Ubuntu LTS | ✅ | ❌ |
node-chrome | Ubuntu LTS | ✅ | ❌ |
Build, test, and distribute multi-arch images
We would also like to share what has been done to ensure that the multi-arch images can be built, tested, and distributed seamlessly.
Utilize Bash scripts and Makefile to wrap the tasks as much as possible. It provides the transparency on how the container images are built and proceed by single command.
Utilize Arm VM’s support on CircleCI to build, test, and deploy ARM64 images. Once GitHub Actions officially supports Arm-based hosted runners, those workflows can easily be moved back to the same place. All the tests done for AMD64 images (including Docker, Docker Compose, and deploy to Kubernetes) are used to verify ARM64 images.
Utilize experimental feature containerd image store in Docker Engine to build and distribute multi-arch images in a simple way.
Hopefully, this will make it easy for the community to find and use multi-arch images to simplify Selenium Grid Server deployment on various platforms.
Stay tuned for updates by following SeleniumHQ on X (Formerly Twitter) or LinkedIn!
Happy testing!
Selenium 4.21 Released!
We’re very happy to announce the release of Selenium 4.21.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: v123, v124, and v125 (Firefox still uses v85 for all versions)
- Selenium has at least 2.4M active users in the last 30 days. 100k more than last month!
- India and United States are the top countries with the most users.
- Python is the most used language from the last 5 releases.
- The most used operating system is Windows, with at least 1.9M users.
- Extensibility points started to be implemented to simplify the integration between Selenium and Appium. Ruby is the first language to implement it.
- Java and JavaScript keep adding more WebDriver BiDi features.
- In Java, it is possible to set parameters for Selenium Manager via system properties.
- Nightly packages are tested daily with the examples from the Selenium documentation.
Noteworthy changes per language
- Java
- Browser containers provisioned in Dynamic Grid will use the hostConfig
- Set test name to video file name in Dynamic Grid
- See all changes
- JavaScript
- Ensure
selectVisibleByText
method is same as other languages - See all changes
- Ensure
- .NET
- Overwrite internal log file if it already exists
- See all changes
- Python
- Moving ignore_local_proxy_environment_variables to BaseOptions
- See all changes
- Ruby
- Rust
Contributors
Special shout-out to everyone who helped the Selenium Team get this release out!
Selenium
Viet Nguyen Duc
Alex
Joe Bandenburg
Oleksandr Kulychok
Sandeep Suryaprasad
Selenium Docs & Website
Arpan
Agustin Pequeno
Chamila Ambahera
Pallavi
Docker Selenium
Viet Nguyen Duc
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
Puja Jagani
Diego Molina
Boni García
Sri Harsha
Nikolay Borisenko
Alex Rodionov
Simon Stewart
Titus Fortner
David Burns
Stay tuned for updates by following SeleniumHQ on X (Formerly Twitter) or LinkedIn!
Happy testing!
Selenium 4.20 Released!
We’re very happy to announce the release of Selenium 4.20.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: v122, v123, and v124 (Firefox still uses v85 for all versions)
- Selenium has at least 2.3M active users in the last 30 days. 500k more than last month!
- Java and JavaScript keep adding more WebDriver BiDi features.
- .NET C# and JavaScript now publish nightly builds to GitHub packages.
- Nightly packages are tested daily with the examples from the Selenium documentation.
- The code used to invoke Selenium Manager has been refactored in all languages, making it easier to maintain and improve.
- The interface has changed and if users were invoking it, they might experience issues. Selenium Manager is still in beta and these type of changes are expected.
Noteworthy changes per language
- Java
- Browser containers provisioned in Dynamic Grid will use the hostConfig
- Dynamic Grid re-fetches browser images if they were pruned during runtime
- Several BiDi additions: Update browsing context create method, between others.
- See all changes
- JavaScript
- Several BiDi additions: Update capture screenshot APIs to include all parameters and remove scroll parameter, between others
- Nightly JS builds are now pushed to GitHub packages
- See all changes
- .NET
- The correct devtools session id is now used after reinitialization
- Nightly .NET C# builds are now pushed to GitHub packages
- See all changes
- Python
- Improvements for type hints in parameters
- See all changes
- Ruby
- Rust
- Use DEBUG level instead of WARN traces in offline mode
- See all changes
Contributors
Special shout-out to everyone who helped the Selenium Team get this release out!
Selenium
Trig
Viet Nguyen Duc
Selenium Docs & Website
Sakif
Viet Nguyen Duc
Agustin Pequeno
Harshit Bhardwaj
Pallavi
Andrew Zipperer
Docker Selenium
Viet Nguyen Duc
Maxim Manuylov
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
Puja Jagani
Diego Molina
Boni García
Sri Harsha
Nikolay Borisenko
Alex Rodionov
Simon Stewart
Titus Fortner
David Burns
Stay tuned for updates by following SeleniumHQ on X (Formerly Twitter) or LinkedIn!
Happy testing!
Selenium 4.19 Released!
We’re very happy to announce the release of Selenium 4.19.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: v121, v122, and v123 (Firefox still uses v85 for all versions)
- Thanks to Selenium Manager’s records usage, we know Selenium has at least 1.8M active users in the last 30 days!
- Java and JavaScript keep adding more WebDriver BiDi features.
- The WebDriver BiDi features in Java have a new home, read it at Puja’s blog post.
Noteworthy changes per language
- Java
se:bidi
was removed from the session response when starting a Grid session, aswebSocketUrl
is enough.- Memory allocation and thread handling was improved in Grid.
- Add missing event handlers for TargetLocator interface in
WebDriverListener
. - Several BiDi additions: adding
setFiles
command of the Input Module, between others. - See all changes
- JavaScript
- Several BiDi additions: adding
setFiles
command of the Input Module, between others. - See all changes
- Several BiDi additions: adding
- .NET
- The
ChromiumDriverService.AllowedIPAddresses
name was corrected - It is now possible to set timeouts via capabilities
- See all changes
- The
- Python
- More network interfaces were added to detect lan ip
- The
install_addon()
(Firefox extensions) was improved to take into account dir paths with trailing slashes - Improvements for type parameters
- See all changes
- Ruby
- Full RBS support was added (#13234)
- See all changes
- Rust
- Improving how MS Edge is downloaded
- Fix how MS Edge is managed in RPM-based Linux
- See all changes
Contributors
Special shout-out to everyone who helped the Selenium Team get this release out!
Selenium
Adam Dangoor
Agustin Pequeno
Scott Babcock
Jani Hautakangas
Selenium Docs & Website
Alpha
Amar Deep Singh
Mohammad Monfared
Docker Selenium
Viet Nguyen Duc
Cedric Roijakkers
Maxim Manuylov
Mårten Svantesson
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
Puja Jagani
Diego Molina
Boni García
Sri Harsha
Nikolay Borisenko
Alex Rodionov
Simon Stewart
Titus Fortner
David Burns
Stay tuned for updates by following SeleniumHQ on X (Formerly Twitter) or LinkedIn!
Happy testing!
Update imports to use BiDi Java
What part of the code base is impacted?
Selenium WebDriver BiDi APIs in Java bindings are impacted.
What is impacted by the breaking change?
The WebDriver BiDi APIs stay as they are, so you can continue to use them. However, the import statements need to be updated.
What is the breaking change?
The import statements need to be updated when using the BiDi APIs.
Before Selenium 4.19:
import org.openqa.selenium.bidi.LogInspector;
import org.openqa.selenium.bidi.BrowsingContextInspector;
import org.openqa.selenium.bidi.Input;
import org.openqa.selenium.bidi.Script;
import org.openqa.selenium.bidi.Network;
After Selenium 4.19 and above:
import org.openqa.selenium.bidi.module.LogInspector;
import org.openqa.selenium.bidi.module.BrowsingContextInspector;
import org.openqa.selenium.bidi.module.Input;
import org.openqa.selenium.bidi.module.Script;
import org.openqa.selenium.bidi.module.Network;
Why the breaking change?
Selenium is actively working to implement the W3C BiDi. The long-term goal of W3C BiDi is to port all W3C WebDriver Classic APIs to use the WebDriver BiDi APIs under the hood. When browsingContext.locateNodes command, which is the BiDi counterpart of findElements command, was introduced, the major goal was to ensure that the ’locateNodes’ command returns a WebElement. This would be make the porting smoother in the future and allows users to continue calling APIs of the WebElement.
During the implementation, a circular dependency was encountered in the underlying build tool Bazel. The solution to this was to follow the best practices of Bazel.
So, the W3C BiDi related classes of a module were grouped into Bazel package. The classes that themselves call commands or events were all grouped under a package named ‘module’. Thus, following the recommended practice and avoiding Bazel’s circular dependency proved to be a win-win solution.
Summary
The W3C BiDi protocol is in under development, and parallelly browsers and clients are working to add the complementary APIs. While Selenium works on implementing it, the protocol is constantly changing, with new modules or APIs being added or existing ones being updated. While the team strives to avoid breaking changes and deprecate APIs for at least 2 versions before removal, it can be challenging to adhere to this for some changes, such as the one described in this blog post.
Selenium 4.18 Released!
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
- Several BiDi additions: Browsing context destroyed event, realm destroyed event, command
- .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
- Fix protocol cdp version for
- Python
- Python for nightly releases
- See all changes
- Ruby
- 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
Oscar Devora
Trig
Manuel Blanco
Oleg Ridchenko
Simon Perepelitsa
Simon K
Valery Yatsynovich
Selenium Docs & Website
Michal Nowierski
Mohammad Monfared
我的饭
Nikolay Borisenko
Pallavi
Docker Selenium
Cani
Bas M.
Viet Nguyen Duc
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
David Burns
Boni García
Diego Molina
Sri Harsha
Nikolay Borisenko
Alex Rodionov
Puja Jagani
Simon Stewart
Titus Fortner
Stay tuned for updates by following SeleniumHQ!
Happy testing!
Selenium 4.17 Released!
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
Andrei Solntsev
James Braza
Lauro Moura
Valery Yatsynovich
Viet Nguyen Duc
Henrik Skupin
Selenium Docs & Website
Oscar Devora
Yevgeniy Shunevych
Docker Selenium
Auto81
Amar Deep Singh
Viet Nguyen Duc
Selenium Team Members
Thanks as well to all the team members who contributed to this release:
David Burns
Boni García
Diego Molina
Sri Harsha
Nikolay Borisenko
Alex Rodionov
Puja Jagani
Titus Fortner
Stay tuned for updates by following SeleniumHQ!
Happy testing!
Selenium Vs … blog posts
The easiest way to clickbait a blog post about automated testing is to compare Selenium against another tool in the space with a catchy title especially when it talks down about the incumbent.
Unfortunately, this can lead to muddying the waters of which features are available in any of the products out there especially when we compare apples to apples.
Selenium has always been a great tool for browser automation. Fortunately for the project, it has become the tool of choice for testing web applications for nearly 2 decades. The area this project has focused on is building out the hard parts of browser automation that are increasingly difficult. Stable APIs and scalability of the infrastructure to run Selenium has always been the priority of the project. It hasn’t focused on how people test with it because there are very good test frameworks out there and having to do it for 5 different languages is a non-trivial amount of engineering effort.
However, some particular misconceptions regularly reappear across these blog posts.
It’s too hard to set up browsers and drivers compared to Playwright and Cypress
This used to be true in the past as you had to download the drivers. This wasn’t too bad for GeckoDriver and SafariDriver as they could handle browser upgrades gracefully. On the other hand, you need to update the drivers for Chromium-based browser for every new release.
For over a year now, Selenium handles this automatically. If it can’t find a ChromeDriver or EdgeDriver, it will download it using Selenium Manager. Since its first release it has improved a lot and it is now probably the best in class since the latest versions of Selenium will even download browsers if it can and use that. Compared to Playwright and Cypress you don’t need to update your dependency on Selenium to update browsers and drivers, you still use the same browsers as your customers, and switching versions becomes a breeze: you don’t also have to change the test framework you’re using. And, let’s not forget that it uses the browser that Google recommends you use for testing.
Setting up a test runner is hard work where Playwright and Cypress have it built in…
Well… maybe? Setting up E2E test frameworks with Selenium isn’t as difficult as some might suggest. The hard part really is making sure that the driver is in the right place and we’ve solved that as discussed above. Once that’s done, Selenium’s approach allows you to use whichever test runner you’re most comfortable with. If you’d like a “batteries included” approach, with Selenium tightly integrated with the test runner, then one of the many projects that use Selenium, such as SeleniumBase, Nightwatch, Serenity, and so on, might be the right tool for you.
One thing to note is that Playwright is the only multi-language browser automation framework like Selenium. However, if you don’t use TypeScript or JavaScript you will still need to do the setup of the test runner yourself. Some testing frameworks have plugins that automatically set up the fixtures you might need. In the JavaScript/TypeScript space if you really need a built-in test runner there are downstream projects like NightwatchJS and tangential projects like WebdriverIO. Downstream projects use our libraries and tangential projects have their own libraries but still follow the WebDriver standard.
Playwright and Cypress can do network interception and allow me to write event-driven code unlike Selenium
Selenium has been able to offer this since Selenium 4 came out. It’s so good that even Playwright suggest you use it for scaling your tests. The Selenium Project won’t be removing this anytime soon as we are dependent on WebDriver BiDi specification being implemented for those features to replace them. Even then Selenium has a history of trying to make sure that upgrades don’t break anything without sufficient warning. It’s why each language provides high-level wrappers, such as the NetworkInterceptor
, that isolate your tests from the underlying technology being used.
Summary
As we have seen from the above Selenium is still as good as the products out there. One thing that is different for Selenium from Cypress or Playwright is that we’re a volunteer-driven project and not commercially backed. Want to help us out? Why not write a blog post about how you’re using the features above or post on social media how these features make your lives easier?