Selenium WebDriver Capability Interoperability Between ChromeDriver and GeckoDriver for Unrecognized Vendor Keys

Question

Unrecognized Vendor Capabilities Handling Across Selenium Browser Drivers

Selenium WebDriver client bindings transmit capabilities as JSON objects during new-session creation. The W3C WebDriver specification defines standard capability names while browser-specific options use vendor prefixes such as goog:chromeOptions and moz:firefoxOptions. However, the specification does not mandate uniform behavior for capabilities a driver does not recognize; implementations can ignore, reject, or transform them depending on driver version and protocol dialect.

ChromeDriver and GeckoDriver have historically exhibited different behaviors when encountering unknown top-level capabilities. Some drivers return invalid argument or session not created errors, while others silently ignore unrecognized keys. This variance becomes more pronounced when switching between W3C protocol and legacy OSS dialect, and Selenium Grid introduces additional complexity by potentially filtering or rewriting capabilities at the hub-node boundary before session creation.

The behavior is inherently version-sensitive and binding-dependent. A capability that succeeds with one driver version may fail with another, even when using the same client binding. Grid proxy and node version skew can alter capability validation independently of client-driver consistency.

What is the current interoperability behavior when an unrecognized vendor-prefixed capability is passed during new-session creation with ChromeDriver and GeckoDriver using the W3C protocol? Does the driver reject the session with an error, silently ignore the capability, or exhibit other handling? How does this behavior differ between driver versions and when using Selenium Grid with mixed hub-node versions?

Tasadduq Burney · Answer

Answer
ChromeDriver generally ignores top‑level vendor‑prefixed capabilities in W3C sessions, while GeckoDriver typically rejects them with an “invalid argument” or “session not created” error; Selenium Grid can cause failures when the hub and node versions differ.
Likely explanation
The specification permits drivers to treat unknown keys as non‑portable, so behavior varies by implementation and version.
Confirmed facts

ChromeDriver (W3C mode) parses the capability JSON, validates known keys, and silently discards any unknown top‑level keys, allowing session creation unless another capability violates the contract.
GeckoDriver validates each top‑level key against its known set and returns an “invalid argument” response, aborting session creation when an unknown key is present.
Selenium Grid adds a validation boundary: the hub may accept the request and forward it to a node; if the hub and node run different driver versions, the node’s stricter validation can cause a session‑creation error despite the hub’s success.
Version differences matter: newer ChromeDriver releases (e.g., 120+) have tightened validation and may reject malformed keys, while older versions tolerate them; GeckoDriver has been strict since 0.30, with limited exceptions in 0.33‑0.35.

To give a precise recommendation for your environment, please provide the exact ChromeDriver and GeckoDriver versions you are running (including any Grid hub and node versions).

Selenium WebDriver Capability Interoperability Between ChromeDriver and GeckoDriver for Unrecognized Vendor Keys

Unrecognized Vendor Capabilities Handling Across Selenium Browser Drivers

1 answer

Answer

Likely explanation

Confirmed facts

Your perspective belongs here.

0 question comments