In Selenium 4's WebDriver BiDi, what do event names like `log.entryAdded` and `network.beforeRequestSent` tell you?

## Every name is `module.member` **WebDriver BiDi** in Selenium 4 is not a flat list of messages. It is split into **modules**, and every command and every event is named as the module, a dot, and the member. Read `log.entryAdded` as "the `entryAdded` event of the `log` module" and `network.beforeRequestSent` as "the `beforeRequestSent` event of the `network` module". Once you see the pattern, an unfamiliar name tells you where to look before you have read a line of documentation. The same naming covers commands. `session.subscribe` is a command of the `session` module, `browsingContext.navigate` a command of the `browsingContext` module, `script.evaluate` a command of the `script` module. Commands and events share one namespace per module, so a module is the complete story about one concern: `network` holds both the events that report a request and the commands that act on one, and you never have to remember two different vocabularies for the same area. ## The module catalogue | Module | Concern | Representative members | |---|---|---| | `session` | the channel itself | `session.status`, `session.subscribe`, `session.unsubscribe` | | `browsingContext` | tabs, frames, navigation | `browsingContext.contextCreated`, `browsingContext.navigationStarted`, `browsingContext.domContentLoaded`, `browsingContext.load` | | `network` | requests and responses | `network.beforeRequestSent`, `network.responseStarted`, `network.responseCompleted`, `network.fetchError`, `network.authRequired` | | `log` | console and script records | `log.entryAdded` | | `script` | evaluating in page realms | `script.evaluate`, `script.addPreloadScript` | | `input` | synthesised pointer and key input | `input.performActions` | | `storage` | cookies and stored state | `storage.getCookies` | | `browser` | the browser instance itself | `browser.createUserContext` | ## Reading the names against a real page Put a hotel room-booking calendar behind it. A tester pages the calendar from September to October, and the page fetches that month's nightly rates. The names line up with what happens: - The tab the calendar lives in announced itself as `browsingContext.contextCreated` when it was opened, and will announce its closing as `browsingContext.contextDestroyed`. - The first load of the calendar produced `browsingContext.navigationStarted`, then `browsingContext.domContentLoaded`, then `browsingContext.load`. - The rates fetch appears first as `network.beforeRequestSent`, carrying the request's method, URL and headers. - The reply appears as `network.responseStarted` and then `network.responseCompleted`; a request that never completed appears as `network.fetchError` instead, and one that hit an authentication challenge as `network.authRequired`. - A warning the date grid writes while re-rendering arrives as `log.entryAdded`, with the record's level, text and timestamp. Every one of those is a separate pushed frame. None of them is an answer to a command the client sent, which is why they all carry a `method` and no command id. ## Why the prefix is load-bearing The module half of the name is not decoration; three behaviours hang off it. 1. **Subscription granularity.** `session.subscribe` accepts a bare module name in its `events` list. Subscribing to `network` takes every event that module defines, which is much shorter than naming five members and is stable when the module gains a sixth. 2. **Payload shape.** Members of a module share vocabulary. The `network` events all describe the same request through its life, so a request id seen on `network.beforeRequestSent` is the one to match against `network.responseCompleted` when you want the pair. 3. **Where to look.** An unknown member is a lookup inside one module's section of the specification rather than a search of the whole protocol. ## A name that does not exist is a defect, not a guess BiDi's catalogue is closed: the modules and members are the ones the specification defines. Names borrowed from other debugging protocols do not work, and neither do plausible inventions. There is no `page` module, no `dom` module and no `window` module in BiDi. Navigation and load belong to `browsingContext`; console records belong to `log`. A subscribe command naming an event the remote end does not know is rejected, and the practical symptom is the one people misread most often: **an empty capture that looks like the browser produced nothing**, when in fact the subscription never took. ## What to take away - BiDi names are always `module.member`, for commands as well as events. - The module prefix is what you subscribe to when you want a whole area. - The common modules are `session`, `browsingContext`, `network`, `log`, `script`, `input`, `storage` and `browser`. - `log.entryAdded` and `network.beforeRequestSent` are the two names most worth memorising, because they are the ones an interviewer will actually ask you to place.