This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Blog Posts - 2023

Selenium 4.11.0 Released!
What's new in Selenium Manager with Selenium 4.11.0
Building Selenium
Java 8 support in Selenium
Selenium 4.10.0 Released!
InvalidSelectorException has changed
Selenium 4.9.0 Released!
Let's meet at SeleniumConf, Once Again!
Headless is Going Away!
Selenium 4.8.0 Released!

Selenium 4.11.0 Released!

Today we’re happy to announce that Selenium 4.11.0 has been released!

By Diego Molina (@diegofmolina) | Monday, July 31, 2023

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

Oscar Devora

Michael Mintz

Nikolay Borisenko

Sandeep Suryaprasad

Hanbo Wang

Sebastian Meyer

Daniel Brown

Vedanth Vasu Dev

Aditya Pratap Singh

Bartek Florczak

João Luca Ripardo

Debanjan Choudhury

Christian Biesinger

Sen ZmaKi

Selenium Docs & Website

Pallavi

Cristian Greco

Gayathri Rukmadhavan

Mikhail C.

nevinaydin

Erick Ribeiro

Docker Selenium

Luis Correia

alb3ric

Bartek Florczak

Mårten Svantesson

wintersolutions

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

Tamsil Sajid Amani

Diego Molina

Sri Harsha

Titus Fortner

Simon Stewart

Boni García

Puja Jagani

Simon K

Alex Rodionov

Krishnan Mahadevan

David Burns

James Mortensen

Stay tuned for updates by following SeleniumHQ!

Happy testing!

What's new in Selenium Manager with Selenium 4.11.0

Selenium 4.11.0 ships very relevant new features of Selenium Manager: support of Chrome for Testing (CfT) endpoints for chromedriver management and automated Chrome management (based also on CfT).

By Boni García (@boni_gg) | Monday, July 31, 2023

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, and with that URL, the driver artifact is downloaded, uncompressed, and stored locally in a cache folder (~/.cache/selenium). The next time the same driver is required, it is used from the cache.

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.

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, i.e., it upgrades automatically and silently to the next stable version when available. On the other hand, CfT is not evergreen, to allow 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!

Building Selenium

How does the Selenium team build Selenium itself, and why did we chose the tools we chose?

By Simon Mavi Stewart (@shs96c@hachyderm.io) | Monday, June 12, 2023

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.

Java 8 support in Selenium

On September 30, 2023, Java 11 will be the minimum version supported by Selenium.

By Diego Molina (@diegofmolina) | Friday, June 09, 2023

“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!

Selenium 4.10.0 Released!

Today we’re happy to announce that Selenium 4.10.0 has been released!

By Diego Molina (@diegofmolina) | Wednesday, June 07, 2023

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

Boris Petrov

Nikolay Borisenko

Maid

Rishav Trivedi

Alex

Michael Mintz

Vladislav Velichko

Moritz Kiefer

Valery Yatsynovich

Oboleninov Anton

Scott Stevens

Sandeep Suryaprasad

Alpatron

Tarek Oraby

robin gupta

Pallavi

Kat Rollo

Brandon Squizzato

Luis Correia

Stephan Erlank

Jordan Zimmitti

Brian Schreder

Selenium Docs & Website

Tarek Oraby

robin gupta

Pallavi

Kat Rollo

Brandon Squizzato

Docker Selenium

Luis Correia

Stephan Erlank

Jordan Zimmitti

Brian Schreder

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

Boni García

Alex Rodionov

Tamsil Sajid Amani

Diego Molina

Titus Fortner

Simon Stewart

Krishnan Mahadevan

Sri Harsha

Puja Jagani

David Burns

James Mortensen

Stay tuned for updates by following SeleniumHQ!

Happy testing!

InvalidSelectorException has changed

⚠️ InvalidSelectorException now extends from WebDriverException

By Mohab Mohie (MohabMohie) | Friday, April 21, 2023

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!

Selenium 4.9.0 Released!

Today we’re happy to announce that Selenium 4.9.0 has been released!

By Diego Molina (@diegofmolina) | Friday, April 21, 2023

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!

Ashley Trinh

Nikolay Borisenko

Ardi

Dana Sherson

Alex

Zach Attas

Ariel Juodziukynas

Henrik Skupin

Abdullah Aslam

ting

fuyou

Johnny.H

Mohab Mohie

Michael Mintz

Michael Render

Tobias Smolka

Étienne Barrié

James Hilliard

Mark Mayo

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

Alex Rodionov

Boni García

Titus Fortner

Diego Molina

Tamsil Sajid Amani

Sri Harsha

Simon Stewart

Krishnan Mahadevan

David Burns

Simon K

Puja Jagani

Stay tuned for updates by following SeleniumHQ!

Happy testing!

Let's meet at SeleniumConf, Once Again!

SeleniumConf is back in person! Yes! It does feel good to say this.

By Manoj Kumar (@manoj9788) | Tuesday, February 14, 2023

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!

Headless is Going Away!

Now that we got your attention, headless is not actually going away, just the convenience method to set it in Selenium

By Diego Molina (@diegofmolina) | Sunday, January 29, 2023

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!

Selenium 4.8.0 Released!

Today we’re happy to announce that Selenium 4.8.0 has been released!

By Diego Molina (@diegofmolina) | Monday, January 23, 2023

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