Selenium – Selenium

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 Vs … blog posts

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

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?

Blog: Removal of AbstractEventListener + EventFiringWebDriver + WebDriverEventListener

Fri, 08 Dec 2023 00:00:00 +0000

Upgrading to WebDriverListener and EventFiringDecorator

Decorating the webdriver

new EventFiringWebDriver(driver); // Old approach
new EventFiringDecorator().decorate(driver); // New approach

Implementing method wrappers

One may find the need to have their own custom implementations be used for underlying decorated method calls. An example may be wanting to use your own findElement implementation to store metadata from web elements. One can go down a deep rabbit hole of decorators ( extending WebDriverDecorator and such ), so to keep things simple we will extend EventFiringDecorator since we want a single decorator to handle all our listener events.

public class WebDriverWrapper implements WebDriver {
 private final WebDriver driver;
 WebDriverWrapper(WebDriver driver) {
 this.driver = driver;
 }
 // custom implementation goes here
 @Override
 public WebElement findElement(final By by) {
 // custom implementation goes here
 return driver.findElement(by);
 }
}

public class testDecorator extends EventFiringDecorator<WebDriver> {

 @Override
 public Object call(Decorated<?> target, Method method, Object[] args) throws Throwable {
 String methodName = method.getName();
 if ("findElement".equals(methodName)) {
 WebDriverWrapper newDriver = new WebDriverWrapper((WebDriver) target.getOriginal());
 return newDriver.findElement((By) args[0]);
 }
 return super.call(target, method, args);
 }
}

Some notes about the above example, we are only overriding the ‘general’ call method and checking the method name against every call made. Without going too deep decorators one can also override calls made by class instances to offer a more targeted approach. Just to expose some more functionality, let’s modify our example. We can modify WebElement context since we might care about child elements and elements found by WebDriver ( WebDriver and WebElement both extend the SearchContext ).

public class WebElementWrapper implements WebElement {
 private final WebElement element;
 WebElementWrapper(WebElement element) {
 this.element = element;
 }
 @Override
 public WebElement findElement(final By by) {
 // custom implementation goes here
 return element.findElement(by);
 }
}

public class WebElementDecorator extends EventFiringDecorator<WebDriver> {
 @Override
 public Decorated<WebElement> createDecorated(WebElement original) {
 return new DefaultDecorated<>(original, this) {
 @Override
 public Object call(Method method, Object[] args) throws Throwable {
 String methodName = method.getName();
 if ("findElement".equals(methodName)) {
 // custom implementation goes here
 WebElementWrapper element = new WebElementWrapper(getOriginal());
 return element.findElement((By) args[0]);
 }
 return super.call(method, args);
 }
 };
 }
}

In the sample above, we are still doing a very similar approach of overriding the call method but now we are also targeting WebElement instances.

Registering Listeners

new EventFiringWebDriver(driver).register(listener1).register(listener2); // Old approach
new EventFiringDecorator(listener1, listener2); // New approach

Listening to Events

A quality of life change that is featured in WebDriverListener class is the use of ‘default’. In Java, the default keyword, when used in the context of an interface method, indicates that the method has a default implementation. If a class implementing the interface chooses not to override the method, it will inherit the default implementation. This change allows for splitting up listeners without needing to implement the unnecessary methods you don’t need or care about.

Listening to specific events using before/after methods call

// Old approach
public class AlertListener implements WebDriverEventListener {
 @Override
 public void beforeAlertAccept(final WebDriver driver) {
 // custom implementation goes here
 }
// implement every method in interface
}

// New approach
public class AlertListener implements WebDriverListener {
 @Override
 public void beforeAccept(Alert alert) {
 // custom implementation goes here
 }
// does not need to implement every method in interface
}

Listening to Generic Events

A change that was brought on is the ability to listen to generic events. One use case is logging information in a parallelized test suite. Rather than create a listener and override every method to add a simple log statement, there is now a simpler alternative of overriding one method call. Below I override beforeAnyCall, but afterAnyCall exists as well which also has the results of the call to the decorated method.

public class Listener implements WebDriverEventListener {
 private static final Logger LOGGER = Logger.getLogger(Listener.class.getName());

 @Override
 public void beforeAnyCall(Object target, Method method, Object[] args) {
 logger.debug("Thread: " + Thread.currentThread().getName() +
 " | Method Name: " + method.getName() +
 " | Method Args: " + Arrays.toString(args));
 }
}

There also was an addition listening to more specific generic events. Going back to the logging example, beforeAnyCall is a good method for debugging information or tracking the actions of a thread but might generate too much noise. In the same use case we might only care about WebDriver or WebElement calls. One can override instances of WebDriver and derived objects( WebElement, Alert, etc.) for before/after events.

public class Listener implements WebDriverEventListener {
 private static final Logger LOGGER = Logger.getLogger(Listener.class.getName());

 @Override
 public void beforeAnyWebDriverCall(WebDriver driver, Method method, Object[] args) {
 logger.debug("Thread: " + Thread.currentThread().getName() +
 " | Method Name: " + method.getName() +
 " | Method Args: " + Arrays.toString(args));
 }

 @Override
 public void beforeAnyWebElementCall(WebElement element, Method method, Object[] args) {
 logger.debug("Thread: " + Thread.currentThread().getName() +
 " | Method Name: " + method.getName() +
 " | Method Args: " + Arrays.toString(args));
 }
}

So that’s some general examples on how to transition your code! 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: Selenium Open Space Conference Oct 28th

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

In less than two weeks, Selenium project is holding space for free and online community meetup, the inaugural Selenium Open Space Conference. Open space conferences are ones where everyone is a speaker, and we co-create our agenda for conversations, questions or answers, workshops, sharing and learning.

We start our 24 hour event at time of 19 years from the tracked Selenium release announcement. We split the day into four segments to facilitate the global community. We set up an event site, and a mechanism to enroll: by pull request or issue to the site in github.

With enrollment, you can already tell if you have a topic in mind you would like to host, and see some (not all!) of the sessions people have in mind for the day.

To run the event, we set up Welo and Miro. Our space has 11 track rooms that each fit up to 150 people regardless of appearance, and we build our agenda on Miro during marketplace of ideas, one for each four time segments.

Welcome from the organizers, would be lovely to see you join us all.

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: InvalidSelectorException has changed

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

Before Selenium 4.8.2 in Java and C#, when an invalid locator was used to identify an element, the resulting behavior would be inconsistent in our bindings.

For example, let’s check the following code:

ArrayList<Class<? extends Exception>> expectedExceptions = new ArrayList<>();
 expectedExceptions.add(org.openqa.selenium.NoSuchElementException.class);
 expectedExceptions.add(org.openqa.selenium.StaleElementReferenceException.class);
 expectedExceptions.add(org.openqa.selenium.ElementNotInteractableException.class);
 expectedExceptions.add(org.openqa.selenium.InvalidElementStateException.class);

return new FluentWait<>(driver)
 .withTimeout(Duration.ofMillis(ELEMENT_IDENTIFICATION_TIMEOUT))
 .pollingEvery(Duration.ofMillis(ELEMENT_IDENTIFICATION_POLLING_DELAY))
 .ignoreAll(expectedExceptions)
 .until(nestedDriver -> {
 nestedDriver.findElement(By.xpath("invalid-xpath")).click;
 });

The expected result before this change would be that the driver waits until the timeout expires and then throw an InvalidSelectorException.

This doesn’t make much sense because a broken/invalid selector would never fix itself, and hence should throw immediately.

This was discussed and agreed during the TLC meeting on August 17, 2022, and implemented through the pull request 11727 and the following commit.

With the changes mentioned above, an invalid selector will throw an InvalidSelectorException immediately.

Please note that this may have an impact on backwards compatibility if you are not expecting this exception to be thrown while handling invalid locators.

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: Let's meet at SeleniumConf, Once Again!

Tue, 14 Feb 2023 00:00:00 +0000

This year is special, thanks to the decision to host an in-person conference after a long hiatus and several years of virtual-only events. We’ve gone out of our way to reflect this feeling at the conference. We have engrossing keynotes, well-researched talks, hands-on pre-conference workshops, hallway tracks, and whatnot!

Here’s a quick list of what to expect!

What’s cooking in Keynotes?

We have Diego Molina kicking things off with ‘Selenium: State of the Union’ where he will talk about all things Selenium, including the project, the code, and the community. Think of it as a journey through the times with Selenium. A must-attend without any shred of doubt!

Next up is Erika Chestnut’s ‘Bigger Than The Box’ where she will focus on the idea of quality and whether it has been restricted to only a single step in the delivery process. It is indeed a dialogue that needs to happen given that our lives revolve around quality.

On day 2, we have first-time SeleniumConf keynote speaker Mark Winteringham from the Ministry of Testing talking about ‘What Exactly Do You Do in Test Automation?’ Is it just about coding and frameworks or is there more to it? How should a test automation practitioner think about their role? Think of this as learning from the ground up or in some cases, back to the basics!

Talks, talks, and more talks

We’ve cast our net far and wide this time around.

Just as a highlight, across the two days, we will cover a diverse range of topics from crawlers, identifying code smells, blended testing, component testing, quality gates, quality metrics to track, testing with real robots, and managing the test data nightmare, among others. Quite a list, huh? Trust me, this is just a sneak peek. You can check out the entire list here.

Also, we’ve got a session on how testing with Selenium is solving unemployment in Africa.

The cherry on the cake is the Q&A with the Selenium Committer’s Panel where you’ll get to pick the brains of the very people who’ve built Selenium.

In a way, we’ve truly tried our best to touch upon the technology, people, and process aspects of testing. We’d love to have you over to catch these experts in action!

Getting your hands dirty with tailored workshops

Testing is all about exploring. How about exploring and diving into something new?

We’ve got community leaders doing deep dives into Selenium, Appium 2.0, how to become a committer, state model-based testing, and driving observability with Selenium Grid.

We truly believe that nothing beats hearing it from the horse’s mouth.

What’s more?

While there are some amazing keynotes, well-researched talks, and structured workshops, we really think the biggest takeaway for any attendee is the people they’ll get to meet. Selenium has been a great example of how the community can come together to build something that is greater than the sum of its parts. A conference like this brings together folks from across the world, with different levels of experience, and puts them under a single roof.

What can be more beautiful than getting to interact with the very community that has built and grown Selenium?

What are you waiting for? Register now! We can’t wait to welcome you to Chicago!

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: Year End Review 2022

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

It was an amazing year here at the Selenium project, and we wanted to remind you of some of the great things we accomplished.

In terms of releases, we continued to build on top of Selenium 4 which was launched in October 2021. This year we published v4.2, v4.3, v4.4, v4.5, v4.6, and v4.7. These releases included improvements, bug fixes, removal of deprecated functionality, improved error handling, updates of the underlying libraries, support for the latest Chrome DevTools versions to keep you in sync with new browser releases, but also new features.

We introduced the first (beta) version of the embedded Selenium Manager. The purpose of this feature is to help you manage your driver binaries without having to manually update them yourself each time a new version is released. We also introduced observability in the Docker-Selenium images. Another major new feature is native support for scrolling in the Actions API. But these are only some of the highlights of what we released. To get the details for each language we support, you can check out their corresponding Changelog pages: Java, Python, Ruby, Javascript, DotNet.

In terms of events and gatherings, in July our Selenium India Conference took place, this time online. It kicked off with an 8 talk pre-conference event, namely Selenium Lite. We then had a full day of workshops, followed by 2 days of conference. We had over 50 speakers and over 800 participants from around the world. The talks focused on Selenium, the Selenium ecosystem, automation, methodologies and best practices. In case you missed some of these talks, you can still watch them here.

We also held 2 test automation summits: one in San Francisco and one in Berlin. During these workshops the participants, together with some of the maintainers of frameworks from the Selenium ecosystem, built their Selenium based projects, added tests, new features and fixed bugs. During the first summit the participants focused on the BiDi protocol, while during the second one the focus was on Appium and mobile automation.

We are kicking off next year with a few surprises. The Selenium Conference in Chicago just announced the Speaker Lineup. Stay tuned for further details!

Many thanks to everyone who has contributed to the Selenium project for all their hard work this year!

And special thanks to all of you who are using, following and supporting the Selenium project.

From everyone here at SeleniumHQ, may you have the best holidays and an amazing new year. See you in 2023!

Blog: SeleniumConf Chicago 2023 Speakers Announced

Thu, 22 Dec 2022 00:00:00 +0000

As many of you know, the Selenium Conference returns to an in-person event next March 28-30, 2023 in Chicago, IL. The Program Chairs & Committee, as well as the Extended Program Review Committee, have been hard at work putting together an outstanding lineup of speakers and workshops, and we’re close to releasing the full agenda and a completely re-branded conference website - stay tuned! In the meantime, we wanted you to be among the first to know who will be presenting, announce a new, additional pre-conference workshop, and provide you with some important updates. Here we go!

Keynote Sessions

There will be four plenary keynote presentations across the 2-day conference. Selenium Core Committer Diego Molina will open the conference on Wednesday with the “Selenium: State of the Union” presentation, followed by Quality & Leadership Coach Erika Chestnut presenting “Bigger Than The Box”, where she shares how she has crossed the aisles to elevate and expand the role quality in the organizations that she has worked for. Day 2 kicks off with Mark Winteringham, Ministry of Testing OpsBoss, presenting “What Exactly Do You Do In Test Automation”. The final keynote session will be a Q&A with the Selenium Committers panel.

Confirmed Track Session Presenters

Following the opening keynote presentations, there will be two separate track sessions running in parallel. Here are the confirmed speakers to date and the presentations they will be giving:

Anand Bagmar, Software Quality Evangelist, Essence of Testing - Metrics to Make Your Quality Practices Effective
Andrew Knight, Developer Advocate, Applitools - Managing the Test Data Nightmare
Benjamin Bischoff, Test Automation Engineer, Trivago N.V. - Identifying Code Smells
Bijoya Chatterjee, Director, Software QE, Sony Playstation - Using A Proxy To Create A Full Stack Automation Suite
Boni García, Staff Software Engineer, Sauce Labs - Selenium Manager: Automated Driver & Browser Management for Selenium WebDriver
Christian Bromann, WebdriverIO Project Lead | Software Engineer, Stateful - Component Testing with WebdriverIO
Corina-Adina Pip, QA Lead , Deloitte Digital - What’s New and Good in Selenium
David Burns, Selenium Core Committer | Head of Open Source Program Office, BrowserStack - Why Browser Engines ≠ Real Desktop Browsers ≠ Mobile Browsers
Dmitriy Gumeniuk, Head of Testing Products, EPAM Systems - Building Quality Gates and Automated Decisions in CI/CD Pipelines. Lessons Learned with 200,000 Regressions.
Eric Frankenberger, DevOps Engineer, Genesys Telecommunications - Deploying a Large Selenium Grid with Video Recording and Autoscaling When Docker Swarm & Kubernetes Are Not an Option
Ibironke Yekinni, Sr. Quality Assurance Engineer, Testify Limited - Solving Unemployment in Africa with Testing and Selenium
Jan Molak, SerenityJS Project Lead, SmartCode Ltd - Creating Faster and More Reliable Web Tests with Blended Testing
Jason Huggins, Jason Huggins, Creator of Selenium | Founder, Tapster - Testing With Real Robots Over the Internet: What Could Go Wrong?
Josh Grant, Developer Advocate, Code Intelligence - Selenium in the Clouds: Using Cloud Service Providers with Selenium WebDriver
Liza Ivanova, Principal Software Engineer, Salesforce - Declarative UTAM Page Objects
Maksim Sadym, Software Engineer, Google - WebDriver BiDi + Selenium. Why and How?
Michael Mintz, Creator of SeleniumBase | Director of Automation, iboss - Python Selenium: Fundamentals to Frameworks (with SeleniumBase)
Robin Gupta, Associate Vice President, Provar - Do You Use Selenium Only for Test Automation?
Roger Abelenda, CTO, Abstracta - Evolve Your Selenium Scripts Into Performance Scripts
Shi Ling Tai, CEO, UI-licious - UNTestable: It’s Just Pressing a Button, How Hard Could it Be?

New Workshop Added - State Model-Based Testing Using Selenium

We’re pleased to announce a new addition to the optional pre-conference workshop day, State Model-Based Testing Using Selenium, led by Ru Cindrea, Managing Partner and Senior Test Consultant, Altom Consulting & Alex Rotaru, Co-owner, Altom Consulting. If you haven’t yet heard of State Model-Based Testing (SMBT) is a testing technique that allows testers to visualize their applications and to generate and automate test flows by using different models of the application under test, thus obtaining a large number of test scenarios. When certain paths of the application are changed, the benefit of using SMBT is that you will only have to modify the states and transitions that apply to that change.

This workshop rounds out the core pre-conference workshop offerings, which include a Selenium Deep Dive session led by Selenium Project Core Committer, Titus Fortner; Driving Observability with Selenium Grid 4, led by Manoj Kumar, VP, Developer Relations at LambdaTest and Selenium Project Leadership Committee member, and Advanced Appium 2.0, with Srini Sekar & Sai Krishna, Lead Consultants at Thoughtworks and long-time Appium workshop instructors.

Workshops are one of the most popular offerings at any SeleniumConf and because class sizes are limited they invariably sell-out. Early Bird ticket sales have closed, but you can still find openings for any of these awesome day-long sessions. Register today and make sure you get a seat at the Conference + Workshop session of your choice.

Wait, Wait - Where is the Fix a Bug, Become a Committer Workshop?

If you’re a long-time follower of past Selenium Conferences, or just happened to attend the July, 2022 virtual SeleniumConf, you may be familiar with the long-standing workshop offering “Fix a Bug, Become a Committer”. This workshop is a bit different in that the goal is to both enhance your own Selenium experience while offering the ability to contribute back to the project. With this, it’s not a learning session, per se, but more of a doing session, and we thought we’d take a different approach this time and make it available at no-charge (other than buying a conference ticket) to a limited number of applicants. If you are familiar with Selenium and want to extend your conference experience an extra day we encourage you to apply. Scholarship applicants (more below) are also welcome to apply.

Announcing the SeleniumConf Chicago 2023 Scholarship Program

The mission of the Selenium project is to educate the QA and developer communities about Selenium, the importance of quality assurance, and automated testing in general. Both the Selenium project and the SeleniumConf organizers very much want everyone to be able to attend the conference, but we know that not everyone’s personal or financial circumstances make this possible - so, we’re setting aside a number of free tickets, and covering travel expenses, as part of our SeleniumConf Chicago 2023 scholarship program.

The program aims to support individuals from underrepresented groups in tech and those facing economic or social hardship so they have access to SeConf content and networking opportunities. If you’re an aspiring software professional looking to use Selenium, or a current one without access to the funds to buy your ticket, you should apply. We will award tickets to people who can show that the knowledge gained will be useful for their ongoing career. The application form will be posted in January, 2023.

Ready to Go, But Your Manager Needs More Convincing?

You’ve now seen the keynotes, the current roster of speakers, and the awesome hands-on workshop descriptions, but you still need more to convince your manager? Download this “Convince Your Boss” email template and tailor it to your specific rationale using the details you’ve gleaned from this post. We’d really like to see you next March in Chicago - so register here!

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: BELLATRIX Test Automation Framework for C# and JAVA

Wed, 16 Nov 2022 00:00:00 +0000

Over the last decade, a large ecosystem of Open Source projects has sprouted up around Selenium. Selenium is often used for automating web applications for testing purposes, but it does not include a testing framework. Nowadays, Selenium Ecosystem initiatives try to give popularity to popular open-source test automation frameworks maintained by people outside of the core Selenium maintainers. One of these frameworks is BELLATRIX, invented by Anton Angelov. It has two versions - C# and Java. A testing framework is an abstraction in which common code provides generic functionality (which can be selectively overridden) for testing different aspects of our applications- UI, API, security, performance, and many others.

BELLATRIX Test Automation Framework

The first version of BELLATRIX appeared on 26 December 2017. It was available only for C# initially, but written on the new back then .NET Core, allowing the framework to be used on all major operating systems (cross-platform). One huge advantage of BELLATRIX is its cross-technology readiness. It allows you to write tests for different technologies such as Web, Mobile, Desktop, and API. In BELLATRIX, we strive for the API for all modules to be as identical as possible.

The usage is simple. We suggest cloning BELLATRIX as a GIT sub-module. Then, any customizations, tests, and project-specific plug-ins should be placed in a project outside the BELLATRIX cloned repository. This way, you can quickly update to the latest version.

BELLATRIX official website, download and releases info

BELLATRIX official C# GitHub Page

BELLATRIX official Java GitHub Page

BELLATRIX C# Documentation

BELLATRIX Java Documentation

Let’s investigate how easy it is to create your first test with BELLATRIX in 15 minutes. The sample will showcase how to create a very basic test login into a website:

Open the BellatrixTestFramework.sln

Under the starthere folder, find the project you prefer: web, mobile, desktop, API

Open the BellatrixLoginTest.cs file. There you will find a sample test automating the login.

[TestClass]
public class LoginTestsMSTest : MSTest.WebTest
{
 public override void TestInit()
 {
 App.Navigation.Navigate("http://demos.bellatrix.solutions/my-account/");
 }

 [TestMethod]
 public void SuccessfullyLoginToMyAccount()
 {
 var userNameField = App.Components.CreateById<TextField>("username");
 var passwordField = App.Components.CreateById<Password>("password");
 var loginButton = App.Components.CreateByXpath<Button>("//button[@name='login']");

 userNameField.SetText("info@yourverybusywebsite.com");
 passwordField.SetPassword("yourverysecretp4ssw0rd$");
 loginButton.Click();

 var myAccountContentDiv = App.Components.CreateByClass<Div>("woocommerce-MyAccount-content");
 myAccountContentDiv.ValidateInnerTextContains("Hello John");

 var logoutLink = App.Components.CreateByInnerTextContaining<Anchor>("Log out");

 logoutLink.ValidateIsVisible();
 logoutLink.Click();
 }
}

All available services are available through the main App class. The Components property provides various Create methods for finding elements. They are generic, so you need to mention the type of the searched element. We have different elements because, for each of them, BELLATRIX offers various additional methods and assertions on top of native WebDriver methods. The sample code uses MSTest as the default test framework, but by changing the attributes, it will also work out of the box for NUnit. Of course, you need to change the base class namespace too.

Why BELLATRIX?

Let’s quickly list some of the essential things the framework brings to the table:

Multiple Test Environments Configuration

Every aspect of the framework can be controlled via a rich JSON configuration designed to work for many test environments. Web Project Configuration.

Customization

One of the hardest things to develop is to allow these generic frameworks to be extendable and customizable. Knowing how essential customization is, we utilize different ways to achieve it. The major one is about writing your own plug-ins.

Test Reliability

One of the biggest problems in test automation is handling timeouts and performing actions on elements that may not be on the page right now. BELLATRIX hides the complexity of searching and waiting for elements. Furthermore, when you perform an action or assertion against an element, we guarantee that once returned, it will be present.

A significant part of your tests are the assertions - checking whether some conditions are met. To handle such scenarios, we created elements Validate methods. They internally handle the whole complexity of waiting for some condition to happen.

updateCart.ValidateIsDisabled();
totalSpan.ValidateInnerTextIs("120.00€", timeout: 30, sleepInterval: 2);
messageAlert.ValidateIsNotVisible();

Complex Controls

BELLATRIX provides API that makes handling HTML tables and grids much easier HTML tables and grids.

Here is an example for asserting grid cells:

TestGrid.ForEachCell(cell => cell.AssertFontSize("14px"));
TestGrid.GetCell("Firstname", 1).ValidateInnerTextIs("Mary");
TestGrid.GetCell(0, 1).ValidateInnerTextIs("John");
TestGrid.GetCell<Employee>(cell => cell.PersonalEmail, 1).ValidateInnerTextIs("mary@hotmail.com");

There is much more complex stuff that you can do with both components so check the official documentation.

Integrations

Seamlessly integrate the framework with your existing tools and processes. Execute tests in the clouds, distribute and publish test results in reporting solutions. Maybe the most significant differentiators of the framework are its many integrations with popular tools such as Jira/qTest/Allure/ReportPortal and clouds such as AWS, Microsoft Azure, + many more. All these integrations leverage BELLATRIX plug-in architecture. For example, we have plug-ins for automatically generating/updating test cases based on our automated tests in qTest and AzureDevops or similarly creating automatic bug reports with steps to reproduce in Jira or Azure.

Dynamic Test Cases

Dynamic test cases are a unique feature in BELLATRIX, where the framework automatically generates test cases in a popular test case management system based on your automated tests. It will populate the title, description, and other necessary properties automatically. Moreover, it will generate human-readable steps and expected results. The most significant benefit is that it will keep up to date with your auto-generated test cases over time, no matter what you change in your tests. It is an excellent functionality which allows the non-technical people of your company to see what your tests are doing.

AI Validation of PDFs and Image

Azure Computer Vision is a service that can be used to extract printed and handwritten text from images and documents with mixed languages and writing styles. In contrast, Azure Form Recognizer is an AI-powered document extraction service that understands your document. You are not limited to PDFs only. You can use the same feature for extracting text from complex images. BELLATRIX comes with similar functionality based on the AWS cloud.

Email Testing

BELLATRIX offers a few utilities for email testing. There are a few scenarios where we need such integration. The first one is related to creating unique email inboxes and using them to submit various online forms. Later, we can read the emails via the services and check the content of the emails. It might be enough to verify the content via regular C#, or in some cases, we might need to interact with the email content in the browser.

There are tons of other integrations that we use on a daily basis in many big enterprise projects, such as cloud secrets management for securely storing credentials and other secrets. All BELLATRIX Integrations

Using BELLATRIX in your projects might save months/years of effort even if you have the required programming knowledge. This way, you can quickly focus on writing automated tests for your project. Usually, there are 4-6 major releases each year, including all bug fixes and new features. Check our release notes history. The framework is fully covered with over 4000 automated tests and offers rich documentation. We make sure to merge the new feature branches only when we are sure that everything is working. If some issue emerges after a major release, it is quickly fixed within a few days.

For feature requests or bug reports, you can submit them to our GitHub repositories. If you believe that the functionality you developed can be added to the CORE framework or you have a bug fix, please submit a PR so we can discuss it and potentially merge it. For anything else, you can reach us via our contact us form.

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: Dev and Beta Channel Browsers via Docker Selenium

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

The Docker Selenium browser Beta and Dev channel releases are now regularly published to Docker Hub and updated every two days. This enables testers and developers to test their applications on pre-release versions of Google Chrome, Mozilla Firefox, and Microsoft Edge before their official releases, using container tools, such as Docker. This empowers teams to stay ahead of the curve and catch potential showstoppers in their CI environment before those issues have an impact on their users.

What are “release channels”?

Here’s some background on release channels: Google, Mozilla, and Microsoft all maintain different “channels” for their respective browser releases. Most end users use the “Stable” channel. The Stable channel releases have passed rigorous testing, and these versions are considered “production-ready”. Up until now, this was the only option for a tester or developer when using Docker Selenium. Today, we’re pleased to announce teams can also test on versions of these browsers yet to be released to the general population. These are the Beta and Dev channels.

For clarity, here is Google’s description of these 3 channels from their “Chrome Release Channels” page:

Stable channel: This channel has gotten the full testing and blessing of the Chrome test team, and is the best bet to avoid crashes and other issues. It’s updated roughly every two-three weeks for minor releases, and every 6 weeks for major releases.

Beta channel: If you are interested in seeing what’s next, with minimal risk, Beta channel is the place to be. It’s updated every week roughly, with major updates coming every six weeks, more than a month before the Stable channel will get them.

Dev channel: If you want to see what’s happening quickly, then you want the Dev channel. The Dev channel gets updated once or twice weekly, and it shows what we’re working on right now. There’s no lag between major versions, whatever code we’ve got, you will get. While this build does get tested, it is still subject to bugs, as we want people to see what’s new as soon as possible.

Standalone Usage:

To use these new Docker Selenium container images in Standalone mode, run the following commands:

Chrome Beta:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-chrome:beta

Chrome Dev:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-chrome:dev

Firefox Beta:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-firefox:beta

Firefox Dev:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-firefox:dev

Edge Beta:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-edge:beta

Edge Dev:

$ docker run --rm -it -p 4444:4444 -p 7900:7900 --shm-size 2g selenium/standalone-edge:dev

Selenium Grid

To run these container images in a Selenium Grid, we’ll use docker-compose. For instance, this example shows how to run a Selenium Grid with Chrome, Firefox, and Edge on the Beta channel:

docker-compose-v3-beta-channel.yml:

# To execute this docker-compose yml file use `docker-compose -f docker-compose-v3-beta-channel.yml up`
# Add the `-d` flag at the end for detached execution
# To stop the execution, hit Ctrl+C, and then `docker-compose -f docker-compose-v3-beta-channel.yml down`
version: "3"
services:
 chrome:
 image: selenium/node-chrome:beta
 shm_size: 2gb
 depends_on:
 - selenium-hub
 environment:
 - SE_EVENT_BUS_HOST=selenium-hub
 - SE_EVENT_BUS_PUBLISH_PORT=4442
 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

 edge:
 image: selenium/node-edge:beta
 shm_size: 2gb
 depends_on:
 - selenium-hub
 environment:
 - SE_EVENT_BUS_HOST=selenium-hub
 - SE_EVENT_BUS_PUBLISH_PORT=4442
 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

 firefox:
 image: selenium/node-firefox:beta
 shm_size: 2gb
 depends_on:
 - selenium-hub
 environment:
 - SE_EVENT_BUS_HOST=selenium-hub
 - SE_EVENT_BUS_PUBLISH_PORT=4442
 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

 selenium-hub:
 image: selenium/hub:latest
 container_name: selenium-hub
 ports:
 - "4442:4442"
 - "4443:4443"
 - "4444:4444"

To run on the more cutting edge – and hence potentially more buggy – Dev channel, simply replace the “beta” tags with “dev”.

Support

These Beta and Dev images represent pre-release browsers and WebDrivers, and they’re not guaranteed to be 100% stable. Should you run into any issues with these images, support from the Selenium community is limited and is dependent on the browser vendors. However, if you believe the issue is related to Selenium, please contact us in the various support channels.

Blog: Scaling a Kubernetes Selenium Grid with KEDA

Fri, 19 Aug 2022 00:00:00 +0000

The Issue

If you have any experience with Selenium Grid and Kubernetes you will probably run into an issue with scaling. Kubernetes (K8S) works wonders for scaling up and down applications based on their CPU and Memory usage, but it is not so straightforward when it comes down to applications like Selenium Grid.

The issue is described quite well in this blog post. But in short, the Horizontal Pod AutoScaler (HPA) that is built into Kubernetes checks (by default) for resource consumption to determine if a deployment needs to be scaled up or down. This becomes an issue for Selenium Grid for a couple reasons:

The browser pods use a variable amount of resources depending on the demand of the current test. This means that all your browser pods may be in use but there isn’t enough CPU usage for the HPA to decide that a scale-up is needed, leaving tests waiting in the queue unnecessarily.
When Kubernetes decides to scale down a deployment it does so (for the most part) at random. You could have 10 tests running on 20 pods and need to scale down. More than likely at least one of the pods asked to terminate will still have a test running, resulting in connection failures.

How KEDA Helps

KEDA is a free and open-source Kubernetes event-driven autoscaling solution that extends the feature set of K8S’ HPA. This is done via plugins written by the community that feed KEDA’s metrics server with the information it needs to scale specific deployments up and down.

Specifically for Selenium Grid, we have a plugin that will tie into our grid to get the information it needs. Example of the used trigger:

triggers:
 - type: selenium-grid
 metadata:
 url: 'http://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'chrome'

All of this gets saved as a Scaled-Object like so:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: selenium-chrome-scaledobject
 namespace: <namespace of your browser pods>
 labels:
 deploymentName: selenium-chrome-node-deployment
spec:
 minReplicaCount: 0
 maxReplicaCount: 80
 scaleTargetRef:
 name: selenium-chrome-node-deployment
 triggers:
 - type: selenium-grid
 metadata:
 url: 'https://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'chrome'

As an added bonus KEDA allows us to scale our deployments down to 0 when there is no use, something the normal out-of-the-box HPA does not allow.

Check more details at the documentation for Scaled-Object in KEDA.

A full example of how to implement this is further down in the article but KEDA solves one of our two issues. Now we can properly scale up and down based on the actual load on the Selenium Grid. Unfortunately scaling down still results in the likely possibility that a pod is still running a test and is told to terminate before it can finish.

Using PreStop and Drain

To combat this we are going to use a combination of K8s PreStop and Selenium Grid’s Drain functionality.

PreStop allows us to set a command or chain of commands that is run to completion before the container is told to stop.
Drain tells the selenium browser pod to finish its current test and then shut down.

Together these look like so in our browser pod yaml:

spec:
 template:
 spec:
 terminationGracePeriodSeconds: 3600
 ...
 ...
 containers:
 lifecycle:
 preStop:
 exec:
 command: ["/bin/sh", "-c", "curl --request POST 'localhost:5555/se/grid/node/drain' --header 'X-REGISTRATION-SECRET;'; tail --pid=$(pgrep -f '[n]ode --bind-host false --config /opt/selenium/config.toml') -f /dev/null; sleep 30s"]

Breaking this down

terminationGracePeriodSeconds is set to however long you wish to give your pods to gracefully terminate before being forced. In this case I give the pods 60 minutes to finish their test when asked to terminate. If you are also scaling your cluster nodes as a part of this you may need to increase the termination grace period for your cluster nodes as well.
When the pod is told to stop, the PreStop command is ran first.
We curl the localhost of our pod to tell it to drain. The pod will no longer accept new session requests and will finish its current test. More information on this can be found in the Selenium Grid documentation.
We then tail the internal node process that will continue to run until the node has been drained.
After this we give the pod 30 seconds to finish anything else before giving the full termination command.

And with that our application can now safely scale down our selenium browser deployments!

From Start to Finish

Install KEDA

You need to use version 2.8.0 or later, you can find the latest version number at the Selenium Grid Scaler docs.
kubectl apply -f https://github.com/kedacore/keda/releases/download/<Version_Number_Here>/keda-<Version_Number_Here>.yaml

Create and apply your scaled object(s)

As described earlier your scaled object will look like so:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: selenium-chrome-scaledobject
 namespace: <namespace of your browser pods>
 labels:
 deploymentName: selenium-chrome-node-deployment
spec:
 minReplicaCount: 0
 maxReplicaCount: 80
 scaleTargetRef:
 name: selenium-chrome-node-deployment
 triggers:
 - type: selenium-grid
 metadata:
 url: 'https://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'chrome'

You will need one of these for every browser you wish to scale.

Things to edit:

namespace should be the namespace that your selenium browser pods exist in
deploymentName are the name of your browser deployment
name (within spec) is also the name of your browser deployment
url is the url of your selenium grid
browserName is the name of the browser you are using
minReplicaCount and maxReplicaCount are the min and maximum pod count you want to have

If you plan to scale with Edge you will need at least version 2.8.0 of KEDA and will need to include sessionBrowserName as well in the trigger metadata:

triggers:
 - type: selenium-grid
 metadata:
 url: 'https://selenium-grid-url-or-ip:4444/graphql'
 browserName: 'MicrosoftEdge'
 sessionBrowserName: 'msedge'

This is due to a name change between the Edge sessions in the queue and the active sessions and is addressed through this pull request.

Once you have that ready just save it as a yaml file and apply with:

kubectl apply -f ./<scaled-object-file-name>.yaml --namespace=<browser_namespace>

Add PreStop commands to your browser pods

Set your terminationGracePeriodSeconds of your deployment to whatever the maximum time you wish to give the pods in order to terminate gracefully. Again you may need to also increase the grace period for your nodepool as well which will vary depending on your K8s provider.
Add the PreStop command to the container lifecycle spec:

spec:
 template:
 spec:
 terminationGracePeriodSeconds: 3600
 ...
 ...
 containers:
 lifecycle:
 preStop:
 exec:
 command: ["/bin/sh", "-c", "curl --request POST 'localhost:5555/se/grid/node/drain' --header 'X-REGISTRATION-SECRET;'; tail --pid=$(pgrep -f '[n]ode --bind-host false --config /opt/selenium/config.toml') -f /dev/null; sleep 30s"]

That is it, your Selenium Grid pods should now scale up and down properly without any lost sessions!

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: Test Automation Summit Berlin

Wed, 13 Jul 2022 00:00:00 +0000

Have you ever wanted to contribute to an open source testing project, but couldn’t figure out where to start? If so, fill out this form to apply for an invitation to join the Open Source Test Automation Summit on August 26 in Berlin, sponsored by Selenium and hosted by Sauce Labs. You can review the list of available projects below and select the one that you’d like to contribute to. We’ll be in touch soon if you are selected to join us.

Update 7/22/2022: Application deadline is July 28! We’ll contact everyone by Friday, July 29.

This will not be your typical workshop. This will be a working session with one or more maintainers of a given project to show you exactly what you need to know to contribute to that project. Selected participants will be required to bring a laptop capable of executing Selenium tests, including a working dev environment for the applicable programming language.

This is a new idea we’re trying out, so space is very limited. If there is sufficient demand we will consider doing more events like this in the future.

Objectives

At the end of the session you will be able to:

Build the project on your computer
Execute the existing test suite for the project
Write new tests for the project
Add a feature or fix a bug

Agenda (subject to change)

Start	End	Activity
0900	0930	Breakfast
0930	1000	Talk: “State of WebDriver Ecosystem”
1000	1100	Lightning talks about participating projects
1100	1200	Split into working groups and walk through projects
1200	1300	Lunch
1300	1630	Continue with working sessions
1630	1700	Wrap up
1700		Happy hour

Participating Projects

The following maintainers are will be present to assist you in working on their project:

Maintainer	Project(s)
Andrei Solntsev	Selenide
Boni Garcia	WebDriverManager
Christian Bromann	WebdriverIO
David Burns	W3C Web Platform Tests, Selenium
Diego Molina	Selenium
Filip Cynarski	FluentLenium
Jan Molak	Serenity/JS
Jani Mikkonen	Robot Framework
Nick Mokhnach	Appium
Ronald Brill	HTMLUnit Driver
Simon Stewart	Selenium
Titus Fortner	Watir, Selenium
Yevgeniy Shunevych	Atata

Update 7/20/2022: Ronald Brill, maintainer of HTMLUnit Driver will now be joining us!

Update 7/25/2022: Yevgeniy Shunevych, maintainer of Atata will now be joining us!

Update 7/26/2022: Simon Stewart, creator of WebDriver, will now be joining us!

Other Projects

Do you maintain an open source project in the WebDriver ecosystem?
Have you written a test framework that uses Selenium that is (or you want to make) open source?
Please fill out this form (provide additional relevant details in the comments), and we will be in touch about future events.

Blog: Removing Legacy Protocol Support

Fri, 20 May 2022 00:00:00 +0000

The Selenium team prides itself on how seriously it takes backwards compatibility. A lot of care has gone into the Java bindings, especially, to ensure very few breaking changes over the years. There is Selenium code written 15 years ago that can still run with Selenium 4 libraries! Providing this exceptional amount of support comes with a large maintenance burden, though, and we need to be able to properly meet the needs of the vast majority of our userbase.

TL/DR:

Support for the legacy JSON Wire Protocol will be removed from Java Selenium 4.9 (other languages have already removed this support)
Protocol conversions will stop in Selenium 4.9 Grid
You can ensure your sessions are W3C compliant by using Browser Options classes instead of the deprecated Desired Capabilities classes (and avoid using “set capability” methods directly)
If you rely on the current protocol conversion functionality, and it works for you, you can continue to use it with Selenium Grid 4.8

By far the biggest challenge in the past seven years of Selenium development has been transitioning the underlying implementation from the legacy JSON Wire Protocol to the new standardized W3C WebDriver Protocol. Because the WebDriver specification was being actively developed at the time, Selenium 3 supported both protocols simultaneously. We implemented “handshake” code to determine which protocol to use. When starting a session, Selenium would package the provided capabilities in both legacy and W3C formats, send them to the driver/server, and use whichever protocol was returned. This worked well for the most part. For many users, no changes were necessary to get W3C compliant sessions from new browsers (Firefox 47+ and Chrome 75+).

For the Java bindings, it was decided to take this approach one step further. Instead of just sending along what was provided in both formats, the code converted capabilities from the legacy protocol to the W3C protocol on behalf of the user. The Selenium Grid makes use of this code, so, regardless of which client language sends legacy capabilities to it, the Grid translates it to the W3C protocol for communication with the driver and then re-translates the results back to the legacy protocol. Because the code must make some assumptions and guesses for this to work, there are a lot of frustrating edge cases.

For Selenium 4.0, the Ruby, JavaScript, and .NET bindings, each removed the handshake code, so no legacy commands are used. Due to some issues that couldn’t be resolved before freezing the 3.x code, Python is waiting until Selenium 4.9 to remove its handshake code. The Selenium team intended to continue to support both protocols in the Grid and Java bindings throughout the 4.x releases, but running test suites written for Selenium 2 on the Selenium 4 Grid resulted in a larger than expected number of failures. Half a dozen bugs were discovered, some with a large effect.

The code in question is sufficiently complex that fixing the bugs without causing new problems would be a significant challenge. As such, we’ve decided to start simplifying the code base again by explicitly not supporting capabilities and commands from the legacy protocol in any of the Selenium codebase. If you are using the latest version of Java Selenium, everything that will be removed has already been marked deprecated, so double-check your usage to ensure there aren’t any surprises.

If you’re interested in the nitty-gritty details of some of the issues we found exploring this problem, you can look at the discussion in Selenium Issue #10374.

For more information on ensuring compatibility with the Grid, please follow our Selenium 4 Upgrade Guide

Blog: Locate your locators - Python bindings changes upcoming

Tue, 01 Feb 2022 00:00:00 +0000

In real estate, the mantra for finding a new house or office space is “location, location, location!”. It could be said that when working with Selenium, a critical aspect of writing tests is “locators, locators, locators!”. Having a robust locator strategy - in your app under test and in your test framework - is highly important for effective testing.

If you are a Pythonista like myself and using Selenium for your test automation, then there are some important changes coming to how locators are defined and used.

Sometime after Selenium 4.2, the Python Selenium bindings will remove locator-specific methods for finding elements. This means that the methods

driver.find_element_by_id("some_id")
driver.find_element_by_name("some_name")
driver.find_element_by_tag_name("some_tag")
driver.find_element_by_css_selector("some_selector")
driver.find_element_by_class_name("some_class")
driver.find_element_by_link_text("some_text")
driver.find_element_by_partial_link_text("some_other_text")
driver.find_element_by_xpath("some_xpath")

will be removed. All of these methods are in fact special cases of

driver.find_element(By_object, "some_locator")

so this approach is now preferred (required, even) with the Python bindings.

Note that it’s good practice to use the By object which has specific values for using particular locator strategies. For example, this line

driver.find_element_by_id("submit_button").click()
driver.find_element_by_css_selectors('.myelement child').text

becomes

driver.find_element(By.ID, "submit_button").click()
driver.find_element(By.CSS_SELECTOR, '.myelement child').text

If you’re really desperate however you can use strings instead of the By object:

driver.find_element('id', "submit_button").click()
driver.find_element('css selector', '.myelement child').text

If you have any plans to upgrade your Selenium client for your Python tests to recent versions of Selenium 4, definitely keep these changes in mind. It’s a good time to update your locator strategy and structure.

(This article was originally posted here. Thanks to the Selenium core contributors for adding this here!)

Blog: IE Mode in Edge supported by IEDriver

Tue, 18 Jan 2022 00:00:00 +0000

With the retirement of Internet Explorer 11 (IE 11) later this year, the folks in Redmond have helped the Selenium project with getting IE Mode in Microsoft Edge working in IEDriver.

IE 11 is due to retire on 15 June 2022 for certain versions of Windows 10. After this date, the Selenium project recommends that you test your IE sites with IE Mode in Microsoft Edge. The Selenium Project will not remove support for IE 11 when it retires but we will not actively fix issues as we have done with previous versions of IE.

The Microsoft Edge team have committed to supporting IE Mode in Edge until 2029 when support for Windows 10 is retired.

Microsoft have written up all the details on how to use and how to migrate your site and we recommend you go read and follow their steps to make sure you’re ready.

Blog: Improving & refining our Docs translations

Fri, 03 Dec 2021 00:00:00 +0000

A while ago, we started to make the Selenium documentation available in more languages. This, in an effort to offer a more inclusive environment for Selenium users who do not have English as their mother tongue.

This effort grew organically, and we got many pull requests adding content for different languages. Over time, some translations got to a very good state, and others didn’t get much attention. This brought the situation where 9 different languages are available in the documentation, but only a few add value to the readers.

To understand which languages are getting visits, we started using Plausible. After a few weeks, we combined the information collected by the analytics tool with the translated percentage per language, and we got the following:

Here’s the number of visitors on the landing page for a given translation in the past 2 weeks, and the percent of documentation pages translated:

Language	Visitors	Translated
ja	1,700	86%
zh-cn	1,500	86%
es	409	42%
fr	203	31%
pt-br	189	87%
de	88	65%
ko	79	68%
nl	22	6%

This shows that the most used languages (aside from English) are Japanese and Chinese, and that the language that has translated most of the content is Portuguese.

Based on this data, we decided to create a new role in the Selenium project: translators. This role will help the project keep in shape the different translations available. Together with that, we are also putting on hold the other available translations until we find volunteers for each language.

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: Stepping Down, Stepping Up

Wed, 27 Oct 2021 00:00:00 +0000

The short version is that I’m stepping down as the Selenium project lead, and will concentrating on pushing WebDriver Bidi forwards. Fortunately, the Selenium TLC have already been steering the project for a while now, so it’s in excellent hands. With Selenium 4 now shipped, the project has a new energy and enthusiasm about it. The future is bright, and I’m looking forward to seeing what it holds.

The longer version? Well, that’s more personal. Let me start at the beginning….

On the 3rd January, 2007 I pushed the initial commit of “WebDriver” to a public repo. I helped with the Selenium 1.0 release, and at the same time made sure that WebDriver emulated the original Selenium RC APIs (in code that lives on to this day). In 2009, Jason Huggins and I merged the Selenium and WebDriver projects, and I took over the leadership of the project. I’ve been the lead for every version of Selenium since then, often being the person who tagged each release in source control, all the way up to the recent Selenium 4 release.

By the numbers, that’s

14 years of WebDriver
12 years of Selenium for me
- Though the first Selenium commits were in 2004
1 10 year birthday celebration
Approximately 130 Selenium releases.
I’ve landed just over 5100 commits
- Which is about 20% of all the changes made to Selenium over the years.
3 different source control systems
5 build systems
14 Selenium conferences
696 different people contributing to the project.

In a way, I blame Michael C for this. He and I worked together at ThoughtWorks in Australia, and had been working with HttpUnit. My assertion was that its API was fine. His was that it should be more Object-Oriented. To explore the idea, I started writing an OO wrapper around HttpUnit, and (of course!) Michael was right.

Or maybe it’s Joe Walnes who I should be talking about. At about the same, he’d been exploring a similar kind of design, but where my API had a Browser, his had the far better sounding WebDriver, and he was generous enough to allow me to use the same name in my next iteration of the idea.

Or, perhaps, it’s Paul Hammant and ThoughtWorks. Paul was the one who suggested Open Sourcing what was then “WebDriver” under the Apache 2 license, and ThoughtWorks supported the decision to make the code available to the world.

In any case, on that day in 2007, I was sitting on the sofa with a glass of red wine, creating the project on Google Code, and thinking (if I was thinking deeply at all) that it’d be nice to get the code out there, and in six months it’ll probably be over. There was absolutely no way I could dream that the project would grow far beyond me, emerging from the Cambrian explosion of the early days of web testing to become first an industry-wide de facto standard, and then, through the work done in the W3C, an actual standard. It’s the only browser automation API that all the browser vendors support.

During these past 14 years, Selenium has been one of the constants of my life. I joke sometimes that I’ve known it longer than my wife and my son, but is it a joke if it’s true?

Why spend that much time and effort on Open Source? On something that you give away for free? Because it’s just been so incredibly rewarding. I’ve had a chance to meet people from all over the globe, work with amazing people from a range of companies I’d never have a chance of working with normally, learn and practice skills I wouldn’t have had a chance to exercise, and to write code that makes people’s lives just a little bit easier.

Most importantly, Selenium has been the way that I’ve met some of the best friends I have in my life. I’ve been very lucky.

I’ve also been lucky to have met and been part of the Selenium community. The conferences and meetups have been a fantastic way to hear about how people are using the tool, and I am constantly impressed by how inventive and thoughtful people can be. The conversations I’ve had at those events have changed how I think about all sorts of things, and not just code. The IRC and Slack channels are vibrant and interesting places to be. There are folks who are there regularly who I’ve never met in person, but who I feel I could count as friends.

Who knew that Open Source could be the source of so much that makes a life bright?

But today, I’m stepping down as the project lead, and will be away from the project until summer, though (in the true spirit of this project), I’m not sure which year.

Why, if all I said above is true, am I stepping down?

The major reason is that the things I like to do, and that I’m good at, are not the things that the project needs right now. It would be hubris to believe that no-one else could do as good a job, particularly when I know how amazing so many people on the project are.

The other reason is that I’m tired. For the past 14 years, much of my free time, as well as hours within work, has been spent working on Selenium. There are other projects and interests I’d like to pour some energy into (just ask me how my Turkish lessons are going!)

In my absence, the project’s “Technical Leadership Committee” will continue to be setting the direction of the project. I’ve been listening to the discussions about where the project can go: it’s going to be brilliant.

That is, while I’m stepping down, the rest of the TLC will be stepping up. They’ve already been running the project for a while. They’ll continue the work we’ve started and carry it forwards and upwards. If you’re reading this, and want to get involved, step in and join the fun. Now’s the perfect time.

When I took over as lead of the Selenium project, Paul joked that he had thrown me the keys and run in the opposite direction. I guess it’s my turn to do that now!

Before finishing, I’d just like to say a heartfelt “thank you” to everyone who’s been involved in the Selenium project. To everyone who’s contributed in some way, or used the code we’ve written, thank you. To everyone who’s filed a bug, thank you too. To all the people who I’ve had the pleasure of so many conversations with, that I would never have met without Selenium, thank you. To my family, who’ve supported me and understood with endless patience that Selenium is a part of our lives, thank you. And to my friends on the project, an extra meaningful thank you.

I won’t be here, but I won’t be far. See you all soon.

Blog: A Tour of 4: New Commands

Wed, 13 Oct 2021 00:00:00 +0000

Before we ship Selenium 4, I thought it would be nice to introduce some of the new features in-depth. Of course, all of the features we’re covering are in the main WebDriver documentation, so if you’re not one for reading blog posts, then feel free to dive in there!

You may well be familiar with how to start a Selenium server: you just do something like java -jar selenium-server-4.0.0.jar standalone and away you go! But with Selenium 4, there are some more things you can do with this jar.

Least obviously, the server jar is an exectuable on its own. If you’re using Linux or macOS, and have Java installed, you can make the jar executable (eg. chmod 755 selenium-server-4.0.0.jar), rename it to something like selenium and put it on your $PATH. That way, rather than writing java -jar ... you can simply run selenium.

Now you’ve done that, if you run selenium with selenium --help you’ll get a handy list of the available sub-commands you can execute. There are the old favourites, such as standalone (for starting a standalone selenium server), and hub and node (for starting a Selenium Hub and Node setup), but there are other interesting commands that are new to Selenium 4.

The first of these is info. We’ve added this to provide easy to find and access documentation on common tasks when using the selenium server. If you run selenium info on its own, you’ll see something like this:

Info
====

You can find out more about topics concerning Selenium Grid by running the
"info" command followed by:

* config - Help on how to configure Selenium
* tracing - Help on how distributed tracing works with selenium
* security - Help on how how to secure communications to and within selenium
* sessionmap - Help on different types of sessionmap and how to start them.


Each topic will give you enough information to help you get started, and contains
some pointers on our site to provide more complete information.

To get more information on a particular topic, just add the name of the topic, for example selenium info security. The hope is that this will make it less daunting to deal with Selenium, and give you a great place to get started with some of the more complicated topics around running a Selenium Grid.

Although it’s incredibly flexible, the selenium command offers a daunting list of command line flags. How are you supposed to remember them all? You’re not! Instead, let selenium completion take the strain for you. If you’re a zsh user, then just source <(selenium completion zsh), and now you have tab completion for the sub-commands, as well as for all the flags, including examples of how to use them.

And, finally, there are some hidden flags. We hid them because they can be a little bit confusing to use or understand what they’re meant to do, but one that can be very useful when debugging how your Grid is configured is the --dump-config flag. When run with a server command such as standalone or hub, it will dump the configuration options used by the Grid as a JSON blob. This can be helpful for tracking down subtle issues with configurations, especially when using environment properties for configuration.

Blog: Announcing Selenium 4

Wed, 13 Oct 2021 00:00:00 +0000

It’s with very great pleasure that we are announcing the release of Selenium 4. This is available for Java, .Net, Python, Ruby, and Javascript. You can download it from your favourite package manager or right from GitHub!

If you’re already a Selenium user, this update should be as easy as just changing your dependency from 3.x to 4.0.0. We’ve worked hard to ensure that this is a “drop-in” upgrade, having focused on keeping the public APIs as stable as possible.

Of course, we’ve made changes, so if you relied on code that was marked as internal to Selenium, or that was deprecated, you might experience some hiccups. Please check our documentation for advice on how to deal with each of the common problems we’re aware of.

But there’s more to Selenium 4 than just being a stable release of what was there before! It brings a whole host of new and exciting features that we hope will make your tests more fun to write, and more stable when you run them. Let’s take a look at some of them!

We’ve introduced “relative locators”. These allow you to specify where on the page an element can be found using language that people use too; things like “above that element”, or “to the right of this other element”. This will hopefully provide you all with a tool to fight against incredibly complex locators, making your tests read a little more clearly, and being more resilient to changes in the page’s DOM. We’re not the first ones to come up with this idea – that honour belongs to Sahi – but if you’ve not used them before, we hope you like them!

If you’re using Firefox or a browser that is derived from Chromium, we’ve added a slew of new capabilities too. These include ways of handling “basic” and “digest” authentication, Network Interception (Are you an HTTP 418?), and also performing commonly requested tasks, like waiting for a change in the DOM, or providing a way to look at Javascript errors.

We’ve added these new features in a way that fits in with our existing APIs. There’s no need to rewrite your tests: just use the new features when it feels right to you.

We have also rebuilt the Selenium Grid, taking lessons from successful projects such as Zalenium and Selenoid to enhance the capabilities. This new Grid runs just as well as a single process, running on a single machine, as it does in the traditional “hub and node” configuration, but it also supports a fully-distributed mode, for use in modern infrastructure running Kubernetes. It has better security baked-in, because we know that securing a Grid can be a difficult task. And at all of these scales and sizes, all the new features we’ve added to the language bindings will work as expected.

The Grid can also manage Docker containers on your local machine, pulling images such as the standalone firefox server so your infrastructure maintenance becomes just a little bit less taxing.

Finally, the Grid is easier to manage. We’ve revamped the UI, placing it on top of a GraphQL model that anyone is free to query and make use of to create their own visualisations or monitors of the Grid. If you’d like to peek into a running session, there are live VNC previews you can open and interact with, providing even better insight into what’s been going on. And if you want even more information, we’ve integrated support for OpenTelemetry into the Grid, so now you can find out exactly what’s happening, where, and when.

I know it’s a cliche to say that it’s a “very great pleasure”, but, being honest with you, it genuinely is. Working on this new version of Selenium has been a chance to work with some amazing engineers, and to be part of a vibrant and energetic community. It’s been a lot of fun to write this code, with these people, and it feels right to say “thank you” to as many of them as possible here. So, without waiting any longer….

We would like to thank all of our users who have helped Selenium be successful over the years. Without you we wouldn’t be where we are today. We would also like to thank all the contributors who have submitted Pull Requests, your contributions make Selenium better. For everyone who’s taken the time to file an issue, and to let us know where there’s been a problem: thank you. We only have a chance to improve when we know that there’s something that needs work!

And finally, thank you to all the Selenium Committers, BrowserStack, Sauce Labs, and our Selenium-Level sponsors for getting this release ready for our users.

We hope you enjoy Selenium 4, and we can’t wait to see what you do with it!

Blog: A Tour of 4: Authentication

Sun, 10 Oct 2021 00:00:00 +0000

The first thing I’d like to introduce you to is Selenium 4’s new-found ability to authenticate to websites. We’ve always been able to handle “form-based” authentication, where a login page has some INPUT elements that you need to enter the user name and password, but handling sites that use basic or digest authentication has always been harder. When using Selenium 3, the advice has been to get the login cookie and set it on your session before accessing the site, but you can now just call a register method to add a user name and password (or, in the future, other kinds of authentication credentials)

In short, in Selenium 4, the process has become less complicated. Perhaps an example will help?

// This "HasAuthentication" interface is the key!
HasAuthentication authentication (HasAuthentication) driver;

// You can either register something for all sites
authentication.register(() -> new UsernameAndPassword("admin", "admin"));

// Or use something different for specific sites
authentication.register(
 uri -> uri.getHost().contains("mysite.com"),
 new UsernameAndPassword("AzureDiamond", "hunter2"));

driver.register(username: 'admin', password: 'admin')

Once you’ve done this, every time the driver loads a page that needs authentication, it will automatically use the user name and password you’ve given it.

This feature is currently implemented on top of Selenium 4’s CDP support, and so only works on those browser that support that protocol, but as we push forwards with development of WebDriver Bidi implementations will switch to that when they can.

Blog: Selenium 4 Release Candidate 2

Sat, 02 Oct 2021 00:00:00 +0000

We’ve listeneed and responded to the feedback from the first release candidate of Selenium 4, and we’re now happy to announce the second release candidate of Selenium 4. This is shipping for .Net, Java, Python, Ruby, and Javascript, and it’s available from all the popular package managers. Go! Try it out!

Unless we encounter a very serious issue or bug, this is likely to be the last release before we push Selenium 4.0.0 itself. What does this mean for you? It’s your last chance to try it on for size and let us know if there are any problems.

In this release, we’ve fixed a nasty issue where closing the first window would cause CDP-related features to break, and have landed a few other cleanups and fixes.

If you’re a Firefox user, please make sure you’re using the very latest version of the geckodriver If you don’t, there may be problems starting sessions as we rely on new features that are included in this new geckodriver release.

If you’re new Selenium 4, then you may want to read this blog post, which explains more, but you might want to have a look at:

Relative locators, which provide a way of finding elements by where they are in relation to one another (like “above”, or “to the right of”)
Authentication on websites using basic or digest authentication
Network interception, which provides an easy easy way to capture and modify HTTP traffic from the browser, as well as making it possible to get HTTP status codes.

Thank you to everyone in the community who’s given us so much helpful and thoughtful feedback on the first release candidate. We really hope that you enjoy this release candidate too!

#Selenium 4 RC 2 has been tagged! This is the final RC before we do our final release! Go start using it! Details of each of the bindings will be found in the thread below!
— David @automatedtester@mastodon.social (@AutomatedTester) September 30, 2021

#Selenium 4.0 RC2 .NET bindings have been released! This will likely be the last release before 4.0 stable release, and the last chance to fix issues before then, so go try it out now. Get the bindings at https://t.co/wGImsWFfCK or via #NuGet.
— Jim Evans (@jimevansmusic) September 30, 2021

#Selenium 4.0.0.rc2 #ruby gem has been published. All of the less pleasant work went into this one - polishing and making sure things match up between the different bindings, etc. This should essentially be Selenium 4, so upgrade already and tell us what you think!
— Titus Fortner (@titusfortner) September 30, 2021

Exciting times! Selenium 4.0 RC2 for Java has been released. We're planning on this being the last release before the stable 4.0 release, so this is your last chance for you to give us feedback and for us to react before then! #selenium4
— Simon Mavi Stewart (@shs96c) September 30, 2021

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: All Selenium downloads are now available on GitHub releases

Tue, 24 Aug 2021 00:00:00 +0000

We announced on a previous entry our decision to move all binaries from Google Storage to GitHub releases. Today, we would like to announce that this work has been completed and all binaries are also available to be downloaded in each one of the releases we have done in GitHub.

In addition to that, all links on our downloads page have been updated, as well as all references to Google Storage in the Selenium code base.

Please note that all past releases will be available both in Google Storage and GitHub releases, but new ones will only be present in GitHub releases. We recommend everyone to modify your download scripts to keep all tooling up to date.

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 downloads will move to GitHub releases

Thu, 19 Aug 2021 00:00:00 +0000

Thanks to Google, Google Storage has been the central place where we have been able to upload all binaries created for each Selenium release, and the place where the Selenium community can download them from. To do so, all people needed to do was visit our downloads page, find the release, and download from there!

The Selenium project hosts its source code on GitHub, and people who are familiar with GitHub know that they can go to the “release” page there to find any downloads for each release of a project.

Rather than hosting the downloads in two places, the Selenium project has decided to host everything on GitHub. We’ll still have links from the download page, but rather than pointing to Google Storage, these will now point to the downloads for each corresponding release tagged on GitHub.

All past releases will be available both in Google Storage and GitHub releases, but new ones will only be present in GitHub releases.

If you are a watcher of the Selenium repo, please note that there will be some noise in your inboxes. We need to create releases for old tags in order to upload the binaries to the release (as is the way GitHub releases work), and we expect to complete this in the next couple of weeks.

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: The Selenium website has a new look!

Mon, 09 Aug 2021 00:00:00 +0000

We have been working hard during the last few weeks redoing our website. Today, we are very happy to share it with the community and we are hoping to get as much feedback as possible!

We did a major revamp to our website two years ago. However, this revamp had some “technical debt” in it…

We're happy to announce that we have (finally!) refreshed our site. Head on over to https://t.co/0xAiKdHrPj and have a browse! Thanks to @diegofmolina and @manoj9788 for making this happen.
— Selenium (@SeleniumHQ) November 12, 2019

We use Hugo to generate our website, and to build a website with Hugo, one normally needs to select a Hugo theme. Our previous website was being built using two different Hugo themes, which was less than ideal. Having two Hugo themes was hard to maintain and accepting contributions was tricky in some cases.

This new website version is using the Docsy theme, made by some folks at Google and used by other popular projects such as Apache Airflow and Kubernetes. Using Docsy helps us to focus more on the website’s content rather than spending lots of time maintaining the underlying details of it.

We all hope you will like the new look and please check our contribution guidelines if you want to contribute to the Selenium website.

Happy testing!

Blog: Public Project Meeting - July 15, 2021

Thu, 15 Jul 2021 00:00:00 +0000

Archived meeting minutes

All meeting minutes can now be found here.

Continuing the series of bi-weekly public project meetings, here is the timeline of the meeting held on July 15, 2021,5:30 PM CET. (Below times are on IST)

Meetings are held on the #selenium-tlc channel on Selenium Slack.

Diego Molina 9:00 PM

Here is the agenda proposal:

General project statistics

Previous meeting: 170 open issues, 23 open pull requests
Currently: 168 open issues, 25 open pull requests
Pending work for the RC 1?
Server - Grid
Hub reports Nodes going down https://github.com/SeleniumHQ/docker-selenium/issues/1257
TimeoutException https://github.com/SeleniumHQ/selenium/issues/9528
IE Stopped working on beta 4 https://github.com/SeleniumHQ/selenium/issues/9600
Language bindings

“se:cdpVersion” is missing in C# and JS

Can all bindings do CDP over Grid?

What are the features present in Selenium 4?

Do all bindings implement them

9:01

@AutomatedTester @Puja Jagani @barancev @jimevans @titusfortner @p0deje @harsha509 please tag the ones I forgot

Titus Fortner 9:02 PM

Documentation theme change update

9:03

(I know you’ve been busy)

David Burns 9:04 PM

The python ci will be green today

Diego Molina 9:04 PM

ok, so let’s start

Regarding bugs we had, with @Puja Jagani we fixed the queue issue, so now the Grid runs enough sessions in parallel

9:05

but we still have 3 open issues, mentioned in the agenda

the timeout one has proven to be hard to reproduce, and therefore fix

David Burns 9:05 PM

I was able to reliably recreate the timeout issue. We were hitting issues in chrome that makes us think chrome is breaking

Diego Molina 9:06 PM

really? The original issue is reported with Firefox

David Burns 9:06 PM

Well, I am getting the timeout message, like with Firefox, with chrome 91

9:07

And it’s like the browser tab has hung/crashed and it manifests

@Puja Jagani has the script and I will help reduce if I can

Simon Stewart 9:07 PM

I need to do some rework of NetworkInterceptor to allow everything to be intercepted

9:08

And I think https://github.com/SeleniumHQ/selenium/issues/9594 is fixed by https://github.com/SeleniumHQ/selenium/commit/0795e78559924be1b69b4c8051f5185f289a4268 #9594 Hub reporting no available nodes after a few hours https://github.com/SeleniumHQ/selenium|SeleniumHQ/seleniumSeleniumHQ/selenium | Apr 8th | Added by GitHub

Diego Molina 9:08 PM

I think @Puja Jagani saw the issue this morning, and she said she was having a look

Simon Stewart 9:09 PM

Darn it. I thought we had it fixed

Though we don’t handle the case automatically. I manually tweaked things to make that work

David Burns 9:09 PM

Shoutout to Puja for looking at ALL THE THINGS

Simon Stewart 9:10 PM

+1000

Diego Molina 9:11 PM

aside from those two, now looking into the IE issue with Grid\

as the Grid is sending and invalid JSON to the IEServer

Jim Evans 9:12 PM

um, se:cdpVersion was implemented in .NET in f10cb89

Simon Stewart 9:12 PM

Woot!

Diego Molina 9:12 PM

great, I will update that item :tada:

on the client side, we still need to find time to build the feature parity doc

9:15

Aside from those items, I can give an update on the new (or reworked) website

9:16

I’ve been spending 1-2 hours per day, for now I am only building the website as it is, not digging into the docs yet

Titus Fortner 9:16 PM

“digging into the docs” == “updating the docs theme” ?

Diego Molina 9:16 PM

so, everything below the about menu is already implemented

Titus Fortner 9:16 PM

or writing the docs

Diego Molina 9:17 PM

and I still need to create pages for these links

Titus Fortner 9:18 PM

that all looks great!

Diego Molina 9:18 PM

to bring context, our website is made from two different Hugo themes, glued together during the build process and a few hacks in between

I’ve found https://www.docsy.dev/ a good alternative since it offers a good theme that can contain both things in one

9:19

this requires to recreate our website using the docsy theme, this part is around 60% done then we need to migrate the existing docs into the new theme

9:20

migrating the docs could be done as a task of copying and pasting or we could see it as a chance to reestructure and organise the existing content, and adding a few things more

9:21

if we want to reestructure, it would be nice to see proposals (like a global TOC with brief descriptions of each item)

9:21

then we can reuse what we have currently, and add what is missing

Titus Fortner 9:22 PM

So code snippets would look like this: https://gist.github.com/harsha509/e690dd2c72f1f5c5785be4c8a47c87fd

Simon Stewart 9:22 PM

Lift and shift first, rework second

Diego Molina 9:22 PM

code snippets is an implementation detail

Simon Stewart 9:22 PM

(That is, let’s open the door to contributions first, then figure out how things should be shaped)

Titus Fortner 9:22 PM

I get it’s implementation

9:23

but that’s the piece I can help with :slightly_smiling_face:

Diego Molina 9:23 PM

right now they look similar to that, so it could be a matter of adjusting things

9:24

ideally, the future for code snippets is to render code stored in GitHub, so we can execute it in GitHub actions for example

Titus Fortner 9:25 PM

I guess the question I had about it (what I tried to figure out a few months back and failed) is if there’s a way to point to a repo like you & Christian built for Docusaurus :smile: (another implementation detail) But… there’s nothing preventing us from writing that code now and figuring it out later

David Burns 9:25 PM

I like rust for this reason… when you run tests it also tests the doc snippets

Titus Fortner 9:25 PM

@p0deje implemented that for Ruby

9:26

it’s really neat

I’ll try to find time to propose something here and try to get feedback from people smarter than I am about these things https://seleniumhq.slack.com/archives/CBH302726/p1626364266427200

Diego Molina

if we want to reestructure, it would be nice to see proposals (like a global TOC with brief descriptions of each item) Posted in #selenium-tlc | Today at 9:21 PM | View message

Diego Molina 9:28 PM

all WIP is committed, so if someone wants to have a look, please check https://github.com/SeleniumHQ/seleniumhq.github.io#wip-moving-to-hugo-docsy-theme

SeleniumHQ/seleniumhq.github.io Official Selenium website and documentation Website https://selenium.dev/

Titus Fortner 9:29 PM

Nice work on all of that

Simon Stewart 9:29 PM

Agreed. Excellent work, @diemol. Thank you

Diego Molina 9:29 PM

hopefully I can have the site migrated in a couple of weeks, then we have focus on the docs

9:30

I do not have any more topics, does anyone have something else?

Titus Fortner 9:31 PM

Hopefully I’ll have all my ${paidWork} code in a good place at that point to take a break

9:32

I also promised the chromedriver team that I’d help fix up their Ruby code

Lots of things to update

9:33

Right now I’m busy updating all of my Java test examples from JUnit 4 to JUnit 5 thanks to @Puja Jagani

Diego Molina 9:36 PM

ok, so it seems we are done with today’s public meeting, thank you everyone!

Blog: Public Project Meeting - June 17, 2021

Thu, 17 Jun 2021 00:00:00 +0000

Archived meeting minutes

All meeting minutes can now be found here.

Continuing the series of bi-weekly public project meetings, here is the timeline of the meeting held on June 17, 2021,5:30 PM CET. (Below times are on IST)

Meetings are held on the #selenium-tlc channel on Selenium Slack.

Diego Molina 8:52 PM

Here is the proposed agenda:

General project statistics

Previous meeting: 167 open issues, 28 open pull requests
Currently: 170 open issues, 23 open pull requests

Pending work for the RC 1?

Server - Grid
Hub reports Nodes going down https://github.com/SeleniumHQ/docker-selenium/issues/1257
TimeoutException https://github.com/SeleniumHQ/selenium/issues/9528

Language bindings

“se:cdpVersion” is missing in C# and JS
Can all bindings do CDP over Grid?
What are the features present in Selenium 4?
Do all bindings implement them?

Release process

After beta 4, we should document how each binding and the Grid are released

Selenium IDE

Who knows what the release process is? What is needed?
Who can help reviewing pull requests?
#1257 Hub reporting no available nodes after a few hours SeleniumHQ/docker-selenium | Apr 8th | Added by GitHub
#9528 java.util.concurrent.TimeoutException thrown at random netty read timeouts with RemoteWebDriver SeleniumHQ/selenium | May 28th | Added by GitHub

8:56 PM

btw, there is no hurry to start, we can also start when most folks are available, I believe this won’t be a long one

Diego Molina 9:01 PM

Just a comment from the increased number of issues… I believe users are starting to give more feedback, so that’s good

9:05 PM

I believe we can slowly jump into the first topic: Pending work for the RC 1?

9:06 PM

Regarding the Grid, I would say it is feature complete

9:07 PM

but we have a couple of bugs we are checking with @Puja Jagani

9:08 PM

I think we can sort them out during the next week (fingers crossed :slightly_smiling_face:)

Diego Molina 9:13 PM

talking about the language bindings, I think the most relevant thing for RC1 is to check feature parity

Titus Fortner 9:14 PM

@AutomatedTester did the shadow Dom work you did end up in geckodriver /Firefox yet?

9:15 PM

I know some bindings implemented the endpoints already

David Burns 9:15 PM

No, it’s nearly done

Maybe I should hand it to the Mozilla folks and maybe they could finish it off

Titus Fortner 9:15 PM

I kind of wanted to wait until I could make sure tests passed and stuff because I never trust myself :)

David Burns 9:16 PM

There is an issue with something between marionette and geckodriver but those are super hard to diagnose

Titus Fortner 9:17 PM

There were some accessibility endpoints? I’m not sure we’ve all added. And I think ruby deprecated methods that other languages implemented with JS

I’ve been meaning to do a deeper dive into the various tests, but haven’t gotten there yet. Ruby broke CDP in last beta release, we need to figure out

9:21 PM

We probably need to do a beta 4.1 just for ruby with that fix

Diego Molina 9:22 PM

Since the VNC stuff has been implemented, I have a bit of time next week to start working in an issue to document feature parity

Titus Fortner 9:23 PM

I’ll dedicate some time this month to helping with it

Probably the last topic is Release process

9:24 PM

Last week Simon recorded the Java release and shared the video so I can document it

It’d be great if the other folks who also do releases do the same, so we can document and potentially automate releases

Diego Molina 9:30 PM

I believe that was everything we had in the agenda

Titus Fortner 9:36 PM

Documentation. We got an offer from a company to help us with documentation so they can integrate it with their product which is an executable browser IDE thing

Or something. I’m not entirely certain, but sounds potentially interesting.

Diego Molina 9:37 PM

tell us more, @titusfortner :slightly_smiling_face:

Titus Fortner 9:37 PM

I at least want to get a demo and see what they mean.

I don’t know more, yet. :)

Diego Molina 9:37 PM

ah ok, they reached out to you privately :slightly_smiling_face:

Titus Fortner 9:38 PM

Yeah, I’ll loop you in when we set up a demo. Might not work for what we need

Diego Molina 9:39 PM

sounds good

Selenium – Selenium

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 Vs … blog posts

It’s too hard to set up browsers and drivers compared to Playwright and Cypress

Setting up a test runner is hard work where Playwright and Cypress have it built in…

Playwright and Cypress can do network interception and allow me to write event-driven code unlike Selenium

Summary

Blog: Removal of AbstractEventListener + EventFiringWebDriver + WebDriverEventListener

Upgrading to WebDriverListener and EventFiringDecorator

Implementing method wrappers

Registering Listeners

Listening to Events

Listening to specific events using before/after methods call

Listening to Generic Events

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