Selenium 4.50 Released: Relative Locators Enter Shadow Roots as Firefox APIs Disappear

Selenium 4.50 arrived on September 30, 2026. The release is aimed less at teams seeking a new test runner than at those maintaining established WebDriver suites. It improves relative locators, removes older Firefox APIs, adds WebDriver BiDi features, and changes parts of the build and release pipeline. ([selenium.dev](https://www.selenium.dev/blog/2026/selenium-4-50-released/))

The change most likely to affect day-to-day test code is in Java and .NET. Relative locators can now start from elements and shadow roots, rather than only from the WebDriver instance. That gives test authors another way to find controls inside component-based interfaces, especially applications that make heavy use of Shadow DOM.

Relative locators fit component-heavy UIs better

Relative locators help when a test identifies an element by its position or relationship to another one. A test might find an input beside a particular label or a button below a known heading. Before Selenium 4.50, Java and .NET users could express those relationships from the driver. The new release also lets them begin the search from an existing element or shadow root.

This matters on pages built from repeated cards, menus, or form sections. Each section may be encapsulated in its own component, so starting the search from the relevant element or shadow root avoids a broad page-level query and makes the test's target easier to understand.

It is still a locator improvement, not a substitute for stable application identifiers. Relative locators can make tests clearer, but they remain exposed to changes in the visual or structural relationship between elements. Suites that rely on long CSS selectors, repeated XPath expressions, or helper methods for crossing component boundaries are the strongest candidates for trying the new behavior.

Deprecated Firefox methods are now gone

Selenium 4.50 removes deprecated Firefox profile extension and certificate methods from every language binding. Java, Python, and .NET now declare Firefox default preferences directly in the binding. ([selenium.dev](https://www.selenium.dev/blog/2026/selenium-4-50-released/))

Projects that deferred updating their Firefox setup code will hit this breaking change during the upgrade. Search the repository for the removed profile extension and certificate APIs first. Shared driver factories, browser capability builders, and test utilities deserve particular attention because the normal end-to-end suite may not exercise them.

Update one binding at a time in a branch, run browser-startup checks separately from functional tests, and verify both local and Grid-based Firefox sessions. A suite can pass on Chrome and still fail before the first test step because its Firefox configuration is obsolete.

WebDriver BiDi continues to expand

Selenium 4.50 adds several BiDi improvements. .NET gets screenshot image sizing, a destination folder for screencasts, text layout mode overrides, and activity source monitoring. Ruby adds BiDi methods for installing and uninstalling web extensions. Java now parses each BiDi command response only once. ([selenium.dev](https://www.selenium.dev/blog/2026/selenium-4-50-released/))

The changes are incremental, but they point to the direction of Selenium's browser automation work. Teams trying BiDi should keep protocol-specific code behind a small abstraction layer. New features can then be adopted without distributing browser-session details across test cases.

Build changes matter to CI owners

Selenium says its release artifacts are now built with remote build execution. Selenium Manager can also be cross-compiled for all supported platforms from Linux or Mac. Publishing Selenium Manager has moved into the snapshot workflow, which reduces the chance of a release shipping without its expected manager artifacts. ([selenium.dev](https://www.selenium.dev/blog/2026/selenium-4-50-released/))

Most QA engineers will not notice these changes. Platform and CI teams should, because Selenium Manager helps set up browser drivers on local machines and in pipelines. After the upgrade, check fresh runners, ARM64 agents, Windows workers, and any environment that relies on automatic driver management.

What teams should do next

• Upgrade a representative Java or .NET suite and test relative locators that start from elements or shadow roots.
• Search for removed Firefox profile extension and certificate methods before changing the dependency version.
• Run dedicated startup checks for Chrome, Firefox, and Edge on local machines and Selenium Grid.
• Review BiDi code for binding-specific behavior, with particular attention to Java and .NET.
• Test Selenium Manager on every CI architecture used by the organization.

Selenium 4.50 does not call for an immediate rewrite. It is a maintenance release with one notable locator change, several BiDi additions, and removals that may expose technical debt. Teams running component-heavy web applications should start by evaluating relative locators. Teams with older Firefox setup code should approach the upgrade as a compatibility exercise rather than a routine version bump.