WebDriver BiDi
Why browserlane is built as a WebDriver BiDi engine, which specification snapshot it tracks, and how engine parity relates to the CLI, MCP, and Skill surfaces.
browserlane is a local-first WebDriver BiDi engine: one Rust binary, bl,
that speaks the W3C's bidirectional automation protocol to Chrome. This
section documents how the engine maps to the specification — capability by
capability, in public.
Spec capabilities
89
65 commands · 24 events
Engine coverage
64%
57 covered · 32 gaps
How it's covered
38 native
19 shimmed / consumed / lifecycle
Verification baseline
57 integrated
awaiting runtime verification — 0 verified so far · 32 not integrated
tracking W3C WD 2026-06-29 · last verified 2026-07-09
What WebDriver BiDi is
WebDriver BiDi is the W3C's bidirectional browser automation protocol: a WebSocket session in which the client sends commands and the browser pushes events (navigation, console, network, dialogs) as they happen. It is the standards-track successor to classic WebDriver's one-way HTTP model, and an open alternative to vendor-specific side-channels like the Chrome DevTools Protocol (CDP).
The specification is organized into modules (session, browser,
browsingContext, emulation, network, script, storage, log,
input, webExtension), each defining commands the client can call and
events the browser can emit.
Why browserlane is built around it
Most agent-facing browser tools sit on CDP. browserlane bets on the standard instead: a protocol with a public specification gives the engine a precise, external definition of "complete" — and that is what makes honest parity tracking possible. The long-term engineering objective is 100% capability parity with the official WebDriver BiDi specification: every module, every command, every event.
That is the goal, not necessarily today's state. The parity matrix shows exactly what is implemented, how, what stays internal, and what is still missing.
The capability-parity principle
The governing principle
Every WebDriver BiDi capability must be reachable through the engine. Only capabilities representing a useful user intention should receive dedicated CLI commands or MCP tools.
This splits parity into two separate questions:
- Engine parity — can the
blengine reach this capability? This is what the coverage numbers above measure, and it applies to the engine alone. - Surface exposure — does a dedicated CLI command or MCP tool exist for it? The CLI and MCP are curated interfaces, not 1:1 mirrors of the specification. A missing dedicated command or tool is not necessarily an engine gap — it is often a deliberate curation decision.
A Skill is not a third protocol implementation either: it teaches an agent how to use the CLI through token-efficient workflows, so its coverage is recorded as documented CLI workflows, never as separate capability.
How events are handled
Many BiDi events never need a user-facing command to count toward engine
parity. The engine subscribes to them and consumes them internally — to drive
auto-waiting, dialog handling, recordings, console and network capture — and
surfaces their value through user intentions like bl record or bl expect.
Internal commands and events still count toward engine parity when they are
genuinely implemented and tested; the matrix labels them Internal or
Consumed event rather than hiding them.
Chrome scope
Chrome is the supported browser. The matrix therefore tracks two things independently for every capability:
- Chrome browser BiDi support — what Chrome itself implements (evidence-gated: recorded as Not verified until checked against WPT or a runtime test).
- Browserlane on Chrome — whether the
blengine's integration of the capability has been exercised and verified against Chrome.
Implementation and verification are also kept separate: a capability can be integrated in the engine while its direct parity test is still pending, and the matrix says so.
Coverage by module
solid = native · faded = covered another way · track = gap — exact counts in the text above each bar
Go deeper
The full capability matrix
Every module, command, and event — searchable and filterable, with implementation, exposure, Skill, and Chrome status per capability.
The status model
What Native, Shimmed, Consumed, Lifecycle alternative, and Missing mean — and how covered/gap, implemented/verified, and public/internal relate.