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
100%
89 covered · 0 gaps
How it's covered
89 native
0 shimmed / consumed / lifecycle
Verification baseline
82 integrated
82 verified · 0 awaiting runtime verification · 0 not integrated · 7 other
tracking W3C WD 2026-06-29 · last verified 2026-07-16
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.
The skill file
Browser automation for AI agents. Use when the user needs to navigate websites, read page content, fill forms, click elements, take screenshots, assert page state, or manage browser tabs.
Parity matrix
The complete capability matrix for WebDriver BiDi — every module, command, and event mapped against the bl engine, its user intention, CLI/MCP exposure, Skill workflow, and Chrome support.