In Selenium, which driver.manage() methods read, add and delete cookies for the current page?

## Where the cookie API lives Selenium keeps cookie work on the **options** object rather than on `WebDriver` itself. `driver.manage()` returns a `WebDriver.Options`, and that single object owns `timeouts()`, `window()`, `logs()` and the five cookie calls. There is no `driver.getCookies()`, which is why every example starts with `driver.manage()`. The store behind those calls is the **browser's own cookie jar** for the running session, reached over the WebDriver protocol. It is not a file your framework keeps and it is not a detached copy: a cookie you add to the shift-rota console is sent on the console's very next request, exactly as if the server had returned a `Set-Cookie` header for it. That is the whole point of the API — it lets a test read and shape real browser state instead of guessing at it. ## The five calls | Call | Returns | What it touches | |---|---|---| | `getCookies()` | `Set<Cookie>` | every cookie the current document's address matches | | `getCookieNamed(String)` | `Cookie` or `null` | the same set, filtered by name | | `addCookie(Cookie)` | nothing | hands one cookie to the browser's store | | `deleteCookieNamed(String)` | nothing | removes cookies of that name for the current document | | `deleteAllCookies()` | nothing | clears everything the current document can see | Four details decide most answers at this level: - `getCookieNamed("rota_view")` **returns `null`** when nothing matches, so the null check belongs at the call site. Selenium does own a `NoSuchCookieException` for the protocol's own get-named-cookie error, but the Java convenience method does not surface it. - `getCookies()` hands back a **copy**. Calling `.clear()` or `.add(...)` on that `Set` changes your local collection and nothing at all in the browser. - `deleteCookie(Cookie)` also exists and removes the cookie the object names; in practice `deleteCookieNamed` is what tests reach for, because you rarely have the original object. - `deleteAllCookies()` is not "reset the browser". It clears what the current page can see, and nothing belonging to any other host. ## The Cookie object you hand to addCookie `org.openqa.selenium.Cookie` is **immutable** — it has readers and no setters, so changing a cookie means deleting it and adding a new one. There are three ways to build one: 1. `new Cookie("ward_filter", "ICU")` — name and value, every other attribute left to the browser. 2. `new Cookie("ward_filter", "ICU", "/wards")` — the same, with an explicit path. 3. `new Cookie.Builder("ward_filter", "ICU").path("/").isSecure(true).build()` — the full form, and the only place `domain(...)`, `expiresOn(Date)`, `isHttpOnly(boolean)` and `sameSite(String)` can be set. Reading a cookie back gives you the same attributes through `getName()`, `getValue()`, `getDomain()`, `getPath()`, `getExpiry()`, `isSecure()`, `isHttpOnly()` and `getSameSite()`. `getExpiry()` returns `null` for a **session cookie** — one with no fixed lifetime, which the browser drops when it shuts down. Note that the value you read back is the value the browser holds, not the object you passed in: if the shift-rota console overwrites `ward_filter` while the test is running, the next read reflects the console's value rather than yours. ## The order the calls have to happen in 1. Navigate to a page on the target origin, so the browser holds a document whose address a cookie can belong to. 2. Add, read or delete cookies. 3. Reload or navigate again if the console has to *act* on a cookie you just seeded — a page that is already rendered will not re-read it on its own. Skipping the first step is the most common failure of all: a brand-new session sits on a blank start page that has no host, and `addCookie` rejects the cookie with `InvalidCookieDomainException`. ## A pass over the shift-rota console ```java driver.get("https://rota.stmartins.test/wards/icu"); driver.manage().addCookie(new Cookie("ward_filter", "ICU")); for (Cookie c : driver.manage().getCookies()) { System.out.println(c.getName() + " -> " + c.getValue()); } driver.manage().deleteCookieNamed("ward_filter"); driver.navigate().refresh(); ``` ## What trips people first - Calling `addCookie` before any `get(...)` and reading the resulting exception as a bug in the site under test. - Expecting `getCookies()` to list the whole browser profile, when it lists only what this document can see. - Mutating the returned `Set` and expecting the browser to notice. - Treating a missing cookie as an exception, and wrapping the read in a `try`/`catch` that never fires. - Seeding a cookie and asserting on the rendered page without a refresh, then blaming the driver when the old view is still on screen. - Building a `Cookie` object and never passing it to `addCookie`, since constructing one changes nothing in the browser by itself. None of these are subtle once the shape of the API is clear: one options object, five calls, a store that belongs to the browser rather than to the test, and a `Cookie` that is only a description of what you want until `addCookie` hands it over.