In short: Chrome has its own control protocol, the Chrome DevTools Protocol
(CDP), the one its developer tools use. It runs over a WebSocket, with no driver
in between. The pure CDP engine (seleniumbase_rs::sb_cdp) speaks it directly;
CDP mode adds it to a WebDriver session.
The protocol#
Chrome opens a debugging port
Started with --remote-debugging-port, Chrome listens for a WebSocket
connection. No other program is needed.
Commands go out
The client sends JSON commands with an id, grouped in
domainsPage, Runtime, Network, Input, DOM, Emulation, ...:
Page.navigate, Runtime.evaluate, Input.dispatchMouseEvent.
Results and events come back
Each command gets a reply with the same id. Chrome also pushes events, such as a finished page load or a network request, without being asked.
The pure CDP engine and Chrome
CDP compared with WebDriver#
| WebDriver | CDP | |
|---|---|---|
| Between test and browser | A driver process (chromedriver) | Nothing |
| Transport | One HTTP request per command | One WebSocket for everything |
| Events from the page | None | Network, console, page loads |
| Browsers | Every major browser | Chromium-based browsers |
| In seleniumbase-rs | BaseCase | sb_cdp::Browser, Page, Locator |
The two ways to use it here#
seleniumbase_rs::sb_cdp launches Chrome and drives it over CDP alone: no
chromedriver to download, version or start. A Locator is lazy: it finds the
element again each time it acts, and waits for it.
DriverMode::Cdp keeps a normal BaseCase WebDriver session and opens a CDP
connection next to it, for what WebDriver cannot do, such as printing to PDF or
setting the time zone. See CDP mode.
The pure CDP engine also has a mock transport (Browser::new_mocked), so code
that drives pages can be tested without starting Chrome.