Selenium 4.51 Release: What's New and How to Upgrade

What Is New in Selenium 4.51?

The GitHub release notes for 4.51.0 list 37 merged pull requests, and 15 of them are tagged as build or test work.

The rest include the changes that reach test code, listed here by binding.

Every binding's 4.51.0 changelog lists support for CDP versions v153, v154 and v155, and the selenium-java 4.51.0 POM pulls in the matching selenium-devtools-v153 through v155 modules. If your suite calls Chrome DevTools Protocol commands, keep Chrome inside that window when you move to 4.51.

Java: ExpectedCondition Drops Guava's Function

The Selenium team announced this change on September 21, 2026 in a migration notice, before the release shipped. In 4.51, ExpectedCondition extends only the JDK interface:

// Selenium 4.50 and earlier
public interface ExpectedCondition<T extends @Nullable Object>
    extends com.google.common.base.Function<WebDriver, T>,
        java.util.function.Function<WebDriver, T> {}

// Selenium 4.51
public interface ExpectedCondition<T extends @Nullable Object>
    extends java.util.function.Function<WebDriver, T> {}

• Not affected - code that passes ExpectedConditions factory methods straight to WebDriverWait.until(), and conditions written as lambdas.
• Affected - variables, fields and method parameters declared as com.google.common.base.Function that hold an ExpectedCondition. They stop compiling.

Search the codebase for Guava's Function type before you bump the version, then retype each hit. apply() has the same signature in both interfaces, so the fix is a drop-in type change: java.util.function.Function, ExpectedCondition with its type parameter, or var.

grep -rn "com.google.common.base.Function" --include="*.java" .

// Before: fails to compile on Selenium 4.51
com.google.common.base.Function<WebDriver, WebElement> condition =
    ExpectedConditions.elementToBeClickable(By.id("submit"));

// After
ExpectedCondition<WebElement> condition =
    ExpectedConditions.elementToBeClickable(By.id("submit"));

The release post says Guava is no longer a dependency of the client bindings. The POMs published to Maven Central show a narrower change.

The selenium-remote-driver 4.51.0 POM still lists com.google.guava:guava 33.7.2-jre as a dependency, with no test or provided scope.

• selenium-java - depends on selenium-remote-driver at compile scope, so Guava still resolves for every selenium-java project and still appears in mvn dependency:tree.
• selenium-support - declared Guava in 4.50.0 and does not in 4.51.0, which is the dependency change that ships with the ExpectedCondition update.

Tracking issue #12737 is still open, and it says removing Guava from the dependencies should be done with Selenium 5, because client code could rely on it being on the classpath.

If your own code imports Guava, declare it in your build file now rather than relying on Selenium's transitive copy.

• getClientFactory() - RemoteWebDriver gains a protected getClientFactory() so subclasses, such as Appium's AppiumDriver, can create their own HTTP and WebSocket clients without the deprecated HttpCommandExecutor fields.
• HttpCommandExecutor fields - client and httpClientFactory, restored as deprecated in 4.50, are now scheduled for removal in 4.53 instead of 4.52, giving Appium time to switch to the new getter.
• Startup failures - the driver no longer leaks its HttpClient when it fails to start, and Java no longer passes a bare --proxy argument to Selenium Manager.

The @selenium/atoms Package and Other JavaScript Changes

Browser atoms are the JavaScript functions Selenium injects into a page for work that needs the browser's own view, such as the getVisibleText atom that reads an element's visible text. In 4.51 the atoms are written in TypeScript.

They are published on npm as @selenium/atoms 4.51.0, a package described as browser injection atoms for Selenium WebDriver.

• Package name - two pull request titles in the GitHub release notes say @seleniumhq/atoms, but the registry name is @selenium/atoms; @seleniumhq/atoms does not exist on npm.
• Removed atoms - the obsolete WebSQL and AppCache atoms are gone.
• Web extensions - the JavaScript driver can install and uninstall web extensions over BiDi and falls back to classic commands when BiDi is not available. Ruby gained the BiDi version in 4.50.
• BiDi classes - the JavaScript BiDi generator can now produce vendor-specific classes.
• Node.js - selenium-webdriver 4.51.0 declares Node.js 22 or later in its engines field.

Python, .NET and Ruby Changes in Selenium 4.51

Python gets support for Python 3.15. The selenium 4.51.0 release on PyPI requires Python 3.10 or later and lists classifiers for 3.10 through 3.15.

If you are starting a new project, the Selenium Python tutorial covers setup.

• WebSocket interval - Python now validates the WebSocket response interval correctly. ClientConfig exposes it as websocket_interval, with a default of 0.1 seconds.
• BiDi window state - setClientWindowState now sends its rect members as sibling parameters.
• .NET - the release post's .NET items, escaping the Edge path on macOS and moving to NUnit 5, change Selenium's own build and test setup rather than the public API. Selenium.WebDriver 4.51.0 on NuGet targets .NET Framework 4.6.2, .NET Standard 2.0 and .NET 8.0.
• Ruby - the BiDi generator types field-less synthetic map records as validated maps. selenium-webdriver 4.51.0 on RubyGems requires Ruby 3.3 or later.

What Changed Between Selenium 4.47 and 4.51?

A suite pinned to 4.46 or earlier picks up every change below on the jump to 4.51. The table keeps changes that remove an API or change behavior, and each release links to its official post on the Selenium blog.

The Firefox CDP block is the change most likely to fail at runtime rather than at compile time. In Python 4.51, execute_cdp_cmd on a Firefox session raises a RuntimeError that tells you to switch to WebDriver BiDi, and Ruby no longer exposes its CDP-backed log and network methods on Firefox. For background on the replacement protocol, read WebDriver BiDi.

Three of the Python fixes in this window came from Navin Chandra, a Selenium committer at TestMu AI: no_proxy matching in 4.47, W3C capabilities built from a list of options in 4.48, and per-connection ClientConfig headers in 4.50.

Is Selenium 5 Released?

No. The Selenium 5 release charter, owned by the Selenium Technical Leadership Committee, is still marked Proposed. It describes Selenium 5 as a focused alignment release in which the bindings converge on consistent behavior, following the existing policy of deprecating an API before removing it.

The charter lists what must land before Selenium 5 ships:

• BiDi support boundary - where the supported Selenium API ends and internal BiDi implementation begins, settled in ADR 17670.
• Network async/event API - one cross-binding API for adding, removing and clearing request, response and authentication handlers, settled in ADR 17685.
• Script and logging async/event API - pinned scripts plus console-message, JavaScript-error and DOM-mutation handlers. Its ADR is still pending.
• Selenium Manager released API - the interface needed to drop Selenium Manager's Beta label and release it independently of the bindings. Its ADR is still pending.

The charter defers several things without rejecting them: routing every classic command through BiDi, deprecating CDP support, convenience helpers such as mock, block and redirect, and a high-level browser context API. WebdriverIO v10 already exposes tabs and frames as values, which is the kind of API the charter leaves out of Selenium 5's required scope.

How to Run Selenium 4.51 With WebDriver BiDi on TestMu AI

The TestMu AI Selenium grid accepts a 4.51 client without changes, and BiDi turns on through the webSocketUrl capability, which the Selenium BiDi integration docs list for Chrome, Firefox and Edge. Those docs use WebdriverIO. The script below does the same with Selenium 4.51 for Python on the Selenium Playground.

import os
import selenium
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.remote.client_config import ClientConfig
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

HUB = "https://hub.lambdatest.com/wd/hub"

options = webdriver.ChromeOptions()
options.browser_version = "latest"
options.platform_name = "Windows 11"
options.enable_bidi = True  # requests webSocketUrl for a BiDi connection
options.set_capability("LT:Options", {
    "username": os.environ["LT_USERNAME"],
    "accessKey": os.environ["LT_ACCESS_KEY"],
    "build": "Selenium 4.51 Release Check",
    "name": "BiDi console capture on Simple Form Demo",
})

# user_agent and extra_headers apply per connection since Selenium 4.50
config = ClientConfig(
    remote_server_addr=HUB,
    user_agent="selenium-4.51-release-check",
    extra_headers={"X-Test-Suite": "selenium-451"},
)

driver = webdriver.Remote(command_executor=HUB, options=options, client_config=config)
console_messages = []
try:
    print("Selenium client:", selenium.__version__)
    print("Browser:", driver.capabilities["browserName"], driver.capabilities["browserVersion"])
    print("BiDi socket:", "yes" if driver.capabilities.get("webSocketUrl") else "no")

    driver.script.add_console_message_handler(lambda entry: console_messages.append(entry.text))

    driver.get("https://www.testmuai.com/selenium-playground/simple-form-demo/")
    wait = WebDriverWait(driver, 15)
    wait.until(lambda d: d.execute_script("return document.readyState") == "complete")
    driver.execute_script("console.log('form ready')")

    field = wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, "input#user-message")))
    field.send_keys("Selenium 4.51")
    driver.find_element(By.ID, "showInput").click()

    wait.until(EC.text_to_be_present_in_element((By.ID, "message"), "Selenium 4.51"))
    print("Displayed message:", driver.find_element(By.ID, "message").text)

    wait.until(lambda d: "form ready" in console_messages)
    print("BiDi console events captured:", len(console_messages))
    print("First event:", console_messages[0])
    driver.execute_script("lambda-status=passed")
except Exception:
    driver.execute_script("lambda-status=failed")
    raise
finally:
    driver.quit()

Install the client with pip install selenium==4.51.0, export LT_USERNAME and LT_ACCESS_KEY from your TestMu AI account, and run the script. The terminal prints:

Selenium client: 4.51.0
Browser: chrome 155.0.8059.80
BiDi socket: yes
Displayed message: Selenium 4.51
BiDi console events captured: 5
First event: form ready

• enable_bidi - sets the webSocketUrl capability. The grid answers with a WebSocket URL in the returned capabilities, which is what the BiDi socket line checks.
• Console capture - driver.script.add_console_message_handler() receives every console message on the page over BiDi, so the count includes the playground's own log lines and varies between runs. The script's own message arrives first.
• readyState wait - the form's script attaches after the document finishes loading. Without the wait, the click can fire before the handler exists and the text assertion times out.
• ClientConfig - since 4.50, Python applies user_agent and extra_headers to every connection the client opens.

That session ran on TestMu AI's Automation Cloud, which records console logs, network logs, video, screenshots and a command log for each session without extra configuration. When an upgraded test hits a removed API, the failing command and the console output sit next to the video in the same view.

• Browser coverage - 3,000+ browser and OS combinations, enough to check Chrome, Firefox and Edge behavior after the Firefox CDP and profile removals.
• No grid to maintain - browsers and drivers are hosted for you; at the time of writing, Chrome latest on the grid reports 155.0.8059.80, inside the CDP window that 4.51 supports.
• Python setup - the Python with Selenium docs walk through running Python Selenium scripts on the grid.

How to Upgrade to Selenium 4.51

The minimum runtimes below come from each package's 4.51.0 metadata on its registry. For Java, the classes in selenium-api and selenium-remote-driver 4.51.0 are compiled for Java 11.

Before you merge the version bump, work through these checks:

• Search Java code for com.google.common.base.Function and retype every variable that holds an ExpectedCondition.
• If you subclass RemoteWebDriver, replace reads of the HttpCommandExecutor client and httpClientFactory fields with getClientFactory() before 4.53 removes them.
• Replace CDP calls on Firefox sessions, such as execute_cdp_cmd in Python, with WebDriver BiDi equivalents.
• Move Firefox extension installs off the profile and onto the driver, for example install_addon() in Python, and use the W3C acceptInsecureCerts capability instead of Java's removed profile certificate setting.
• Run the full suite across every browser you support, because the Firefox CDP block only shows up at runtime.

To confirm which version a project resolves after the bump, run the command for its binding. For the release history before 4.47, see the Selenium latest version page.

python -c "import selenium; print(selenium.__version__)"
npm ls selenium-webdriver
mvn dependency:tree -Dincludes=org.seleniumhq.selenium
dotnet list package
gem list selenium-webdriver

The Selenium project's AI agents with Selenium post says coding agents tend to reproduce outdated Selenium 2 and 3 patterns, such as DesiredCapabilities and fixed sleeps. It recommends pointing agents at the curated selenium.dev/llms.txt index and adding a rule to AGENTS.md or CLAUDE.md: if an API cannot be found in the current documentation, it does not exist.

TestMu AI's open-source agent skills include a Selenium skill that generates WebDriver tests for local runs and the TestMu AI cloud.

Getting Started With Selenium 4.51

Run the Guava search and a search for Firefox CDP calls first, then bump one binding to 4.51.0 in a branch and run the full suite; the failures it prints are your upgrade list. Once it passes locally, follow the getting started with Selenium 4 docs to point the suite at the TestMu AI grid and run it across the browsers your users have.