In Selenium Grid, what does the se: capability namespace hold, and what do se:name and se:recordVideo do?

## Why a prefixed key exists at all The W3C WebDriver protocol validates a new-session request: a top-level capability key it does not recognise is an error, **unless** the key contains a colon, which marks it as an **extension capability**. That escape hatch is what lets a browser vendor ship its own block of settings, and it is what lets Selenium ship its own. `se:` is Selenium's prefix, and in Selenium 4 the keys under it are instructions to **the Grid and its nodes** — not to the browser, which never sees them. A client sets them on the object it already builds, because a typed options class is a capability map underneath: ```java ChromeOptions options = new ChromeOptions(); options.setCapability("se:name", "canvas drag adds a rating block"); options.setCapability("se:recordVideo", true); ``` ## The keys a client sets - **`se:name`** holds a string: a human-readable label for the session. It is what turns a wall of identical session ids in the Grid console into something a person can scan, and on SeleniumHQ's `docker-selenium` node images the recorder uses it to name the video file it writes. Setting it to the test's own name is the usual choice for a survey-builder canvas suite, so a failed run maps to an artefact without anybody correlating timestamps by hand. - **`se:recordVideo`** holds a boolean. On a Grid whose nodes have a recorder attached, `true` asks for that session to be captured. It is a request, not a guarantee: the capability only does something where the recording machinery already exists. - **`se:downloadsEnabled`** holds a boolean and opts the session into the Grid's managed downloads area, so files the browser saved on the node can be listed and fetched afterwards rather than being stranded there. ## The keys the Grid hands back Not every `se:` key travels in your direction. Some appear in the **granted** capabilities the Grid returns when the session is created, and the client reads them with `getCapabilities()`: - **`se:vncEnabled`** is reported as `true` by a node that offers a live VNC view of the session, which tells a client that watching the run is possible at all. | key | who sets it | what it holds | what reads it | |---|---|---|---| | `se:name` | the client, in its options | a label string | the Grid console and the node's recorder | | `se:recordVideo` | the client, in its options | a boolean | a node with a recorder attached | | `se:downloadsEnabled` | the client, in its options | a boolean | the node's download handling | | `se:vncEnabled` | the Grid, on the created session | a boolean | your code, via `getCapabilities()` | ## What `se:` keys deliberately do not do 1. They do not configure the browser. Nothing under `se:` reaches Chrome or Firefox as a launch setting; the browser-specific blocks are a separate namespace entirely. 2. They do not change routing. The Grid picks a slot on the standard capabilities, so a session with a label lands exactly where the same session without one would have landed. 3. They do not fail loudly when unsupported. Because the protocol treats a colon-bearing key as a legitimate extension, a node that knows nothing about the key simply carries it and does nothing. Asking for a recording on a Grid with no recorder produces a perfectly healthy session and no video. That last point is the one that costs people an afternoon: the absence of an error is not evidence the key worked. ## Checking what your Grid honours Because unknown extension keys are silent, prove the effect rather than the spelling: - start one session with the key set, and read the granted capabilities back with `getCapabilities()`; - look for the session under the label you set, in the Grid's own view of running sessions; - for a recording, check that an artefact exists after the session ends, named as you expect; - keep the spelling exact — capability keys are case-sensitive, and `se:recordvideo` is simply a different, unrecognised extension key that will never be an error. ## Why this matters on a shared Grid A Grid serving several suites at once is anonymous by default: sessions are ids and browser names. `se:name` is the cheapest labelling any team can adopt, and it is what makes the difference between a canvas run whose failing session can be found later and one that cannot. `se:recordVideo` turns a hard-to-reproduce failure — a drag that dropped a rating block in the wrong place once in fifty runs — into something reviewable. Both are client-side, both are one line, and neither changes where the session runs.