Which protocol does Cypress 16 use to drive Chrome, and which one drives Firefox?
answer
- Two processes need a wire between them
- The Chromium family shares one protocol
- Firefox dropped that protocol entirely
- A remote debugging port is involved
- WebDriver BiDi is the Firefox route
basics
~20 sCypress drives Chrome, Chromium, Edge and the bundled Electron browser over the Chrome DevTools Protocol, and Firefox over WebDriver BiDi. The Node process speaks that protocol; your spec code still runs inside the browser next to the application.
solid answer
~50 sCypress is two processes. The spec runs in the browser alongside the application, and a Node process launches and supervises the browser. Between them sits an automation channel: for Chrome, Chromium, Edge and the bundled Electron browser it is the **Chrome DevTools Protocol**, reached on a remote debugging port; for Firefox it is **WebDriver BiDi**, because Firefox removed its DevTools Protocol support. Most of what a test does never touches that channel — `cy.get()`, `.click()`, `.should()` and the retry loop all happen in the page. The channel carries only what the page cannot do to itself: capturing a screenshot, reading and setting cookies at the browser level, saving downloads to disk, dispatching native key events for `cy.press()`, focusing the browser window, and clearing browser state between specs. `Cypress.browser` tells a spec which family it is running in.
go deeper
Know that Cypress is two processes — a spec inside the browser and a Node process outside it — and that the browser is remote-controlled by the second one. Naming the two protocols is a bonus at this level.
Be ready to name the protocol per browser family and to sort a list of commands into in-page work and channel work. Explaining why screenshots and cookies must leave the page is the core of the answer.
Show you have felt the consequences: a command unavailable on one browser, a launch that fails before any test runs, a browser-specific quirk that turns out to live in the automation layer rather than the spec.
Frame the channel as a dependency the organisation owns: which browsers the suite commits to, what happens when a capability exists on one wire and not the other, and how much of the suite is allowed to require it.
Cypress is often described as "running inside the browser", and that is true of your spec. It is not the whole picture: the browser has to be launched, watched, and occasionally *ordered about* from outside, and that is a job for a process the page cannot host. Cypress therefore always has a Node process alongside the browser, and between them a channel over which the browser itself is driven. ## Why a channel is needed at all Code inside a page is deliberately boxed in by the web platform. It cannot take a screenshot of the viewport, read a cookie marked `HttpOnly`, decide where a downloaded file is written, dispatch a key event the browser treats as trusted, or bring the browser window to the front. Every one of those is something a test runner needs. So Cypress asks the browser to do them, from outside, over a remote-control protocol. ## Which browser speaks what | Browser family | Channel | Notes | |---|---|---| | Chrome, Chromium, Edge | Chrome DevTools Protocol (CDP) | reached on a remote debugging port opened at launch | | Electron (bundled with Cypress) | Chrome DevTools Protocol (CDP) | same protocol and also a debugging port, but outside branded-browser policy | | Firefox | WebDriver BiDi | Firefox deprecated and then removed its CDP support, so BiDi is the only route | | WebKit | a separate automation client | several channel-backed capabilities are simply unavailable there | The important consequence is that **the same spec-side API sits on two different wires**. `cy.press(Cypress.Keyboard.Keys.TAB)` becomes a pair of the DevTools Protocol's own `Input.dispatchKeyEvent` calls on one wire, and one of BiDi's `input.performActions` requests on the other — and BiDi expects WebDriver's own codepoints for named keys, so Cypress translates them. You never see any of that; you see one command that either works or reports that this browser family cannot do it. ## What actually crosses the channel - **Screenshots** — `cy.screenshot()` and the automatic screenshot on failure are captured by the browser, not by the page. - **Cookies** — the browser-level cookie store behind `cy.setCookie()`, `cy.getCookies()` and the clear commands. - **Downloads** — where a downloaded file is written, and the events announcing that one started and finished. - **Native key events** — `cy.press()`, which is the whole reason that command exists. - **Window focus** — bringing the browser window forward so the page behaves as it does for a real user. - **State resets** — clearing browser storage and caches so the next spec starts clean. - **Navigation of the app frame** — reloading it and stepping through history for `cy.reload()` and `cy.go()`. ## What does not Everything that touches the DOM. `cy.get()`, `cy.contains()`, `.click()`, `.type()`, every assertion, the retry loop that re-queries until an assertion passes, and every `.then()` callback all execute in the browser, in the same event loop as the application. That is why Cypress can hand you a live jQuery object and why a failed assertion knows the element it was looking at. Nothing there is an out-of-process round trip. ## Why a candidate is asked this Three practical things fall out of the split, and they are what the question is really probing: 1. **Some commands are channel-only, so their availability is not uniform.** `cy.press()` needs a native-key channel; a browser family without one reports the command as unsupported rather than degrading to a simulated event. 2. **The channel can be closed from outside your project.** If the browser launches but Cypress cannot reach it on the remote debugging port, the run fails before a single test executes — a class of failure that has nothing to do with your specs. 3. **Cross-browser differences live down here.** Two channels means two implementations of the same capability, which is where the occasional browser-specific quirk comes from. ## Reading it back in a spec A spec can ask which family it is in with `Cypress.browser`, and `Cypress.isBrowser()` gives a boolean for the same thing. On a bank statement suite where one spec tabs through the filters natively, guarding that spec on browser family is more honest than letting it fail on the browsers that have no native-key channel. The rest of the suite — visiting the page, filtering, asserting rows, clicking Download — is pure in-page work and runs identically everywhere.
- Why doesn't Cypress drive Firefox over the Chrome DevTools Protocol any more?Firefox deprecated its CDP implementation and then removed it, so there is nothing left to speak. Cypress launches Firefox with WebDriver BiDi as the active remote protocol and drives it from there. The spec-side API is unchanged — only the wire beneath it differs, and Cypress translates each automation request into the BiDi equivalent.
- In a Cypress test, which work does not travel over the automation channel at all?Everything that touches the DOM. `cy.get()`, `.click()`, `.type()`, assertions and the retry loop all run in the browser, in the same event loop as the application. The channel is reserved for what the page cannot do to itself: screenshots, browser-level cookies, downloads, native key events and clearing browser state between specs.
Your spec works the shop floor inside the browser. The automation channel is the service door at the back, used only when something has to be asked of the building itself — the locks, the post, the lights.
saying these in an interview costs you the question
- Says Cypress drives every browser over WebDriver
- Thinks every cy command is a protocol round trip
- Believes Cypress still drives Firefox over CDP
- Assumes CDP requires DevTools to be open
- Confuses the automation channel with the browser's network stack