In Selenium, which cookies does driver.manage().getCookies() actually return for the page currently loaded?
answer
- Scoped to one address, not the profile
- The set follows the current document
- Path matching quietly hides some cookies
- The driver is not page script
- HttpOnly cookies still come back
basics
~20 sIt returns the cookies associated with the address of the document the browser currently holds, with all their attributes. It is not the whole browser profile, and unlike a script read it also includes cookies marked HttpOnly.
solid answer
~40 s`getCookies()` returns a `Set<Cookie>` for the **address of the document currently loaded** — cookies on that host, cookies on a parent domain that host is under, and only those whose path the current URL matches. It is not a dump of the browser profile: navigate the shift-rota console from `rota.stmartins.test` to another host and the same call returns a completely different set. Because the driver reads the browser's cookie store over the WebDriver protocol rather than evaluating `document.cookie`, cookies marked `HttpOnly` come back too, with `isHttpOnly()` true, and every cookie arrives with its `domain`, `path`, `expiry`, `secure` and `sameSite` attributes rather than as a flat name-value string. The same scoping applies to `deleteAllCookies()`, so clearing state across two hosts means visiting each one.
go deeper
Know that the call returns the cookies for the page you are on, not the whole browser, and that each entry carries attributes rather than being a plain string.
Explain the scoping rule in terms of the current document's address, including path matching, and say why HttpOnly cookies still come back through the driver.
Show what this costs a suite: per-host cleanup, cookie assertions paired with a URL check, and named-cookie assertions instead of counts.
Frame where browser-state verification belongs across a test portfolio, and what a suite should assert about session state versus what it should leave to the service that issues it.
## What "the cookies for this page" means The WebDriver protocol defines the get-all-cookies command as returning the cookies **associated with the address of the current browsing context's active document**. Three parts of that sentence do real work: - **Address** — the host and path of the URL currently loaded, not the browser's whole history. On `https://rota.stmartins.test/wards/icu` you get cookies for `rota.stmartins.test` and for any parent domain it is under, such as one set on `.stmartins.test`. - **Current browsing context** — the window, tab or frame the driver is pointed at right now. Switching to another window with a different origin, or into a cross-origin frame, changes the answer. - **Active document** — the page as loaded. The set is recomputed on every call; there is no cache to invalidate. Path matching is part of it too. A cookie stored with `path=/reports` is not associated with a document at `/wards/icu`, so it does not appear, even though it is sitting in the same browser. ## The driver's store versus a script read | | `driver.manage().getCookies()` | `document.cookie` evaluated in the page | |---|---|---| | Shape | `Set<Cookie>` with typed attributes | one string of `name=value` pairs | | Attributes | `domain`, `path`, `expiry`, `secure`, `httpOnly`, `sameSite` | none — values only | | `HttpOnly` cookies | included | hidden by the browser | | Route | the browser's cookie store, over the WebDriver protocol | script running inside the page | This is the practical reason the cookie API exists at all. The shift-rota console's own session cookie is normally marked `HttpOnly` precisely so that page script cannot touch it — and a test that reads it through `executeScript` will conclude it is missing. The driver is not running inside the page's script sandbox; it asks the browser for the cookie store directly, so the flag does not hide anything from it. Reading a cookie this way tells you the flag is set (`isHttpOnly()`), which is itself often what the test wants to assert. ## What changes the visible set 1. **Navigating to another host.** `driver.get("https://reports.stmartins.test/")` and the rota console's own cookies drop out of the result. 2. **Navigating to another path** under the same host, when cookies were stored with a narrower `path`. 3. **Switching browsing context** — another tab on a different origin, or a cross-origin frame — because the command follows the active document. 4. **Time.** A cookie whose expiry has passed is gone from the store; a session cookie survives navigation but not the browser. ## Consequences for a test suite - `getCookies()` is a **diagnostic you can trust**: what it returns is what the browser will actually send on the next request from that page. - `deleteAllCookies()` inherits the same scope. "Clear all cookies" clears the ones the current page can see, so a suite that touches both the rota console and a separate reporting host needs a visit and a clear per host. - Asserting "the cookie is gone" while the browser is on the wrong page is a false green. Check `getCurrentUrl()` alongside the cookie assertion when a cleanup test looks suspiciously easy. - A cookie count is a fragile assertion. Analytics, consent banners and the console's own preferences all add entries. Assert on `getCookieNamed(...)` and the attribute you care about instead. - The scope cuts both ways when seeding: a cookie added while the browser is on the wrong host lands on that host, not the one the test meant. ## Reading one attribute safely ```java driver.get("https://rota.stmartins.test/wards/icu"); Cookie session = driver.manage().getCookieNamed("rota_session"); assertNotNull(session, "no rota_session cookie on this page"); assertTrue(session.isHttpOnly()); assertEquals("/", session.getPath()); ``` The null check is not ceremony: a cookie that is merely out of scope for the current address reads exactly like a cookie that was never set, and the two have completely different diagnoses. If the assertion fails, print `driver.getCurrentUrl()` beside the whole set from `getCookies()`; nine times out of ten the URL explains the absence on its own. ## Where this stops The driver reports what the browser holds; it does not decide it. Whether a cookie is stored at all, and whether the browser sends it on a given request, are the browser's own rules applied to the attributes the cookie carries. Selenium's part is narrow and worth stating plainly in an interview: **a faithful read and write of the store for the document you are on**, and nothing beyond it.
- A cleanup step calls deleteAllCookies() once and the next test still sees stale state. What is the likely cause?The clear ran while the browser was on a different address from the one that owns the stale cookies — another host, or a path narrower than the cookie's own. The call only removes what the current document can see. Visit each host that holds state and clear there, or start a fresh browser session instead.
- Why can a test read the console's session cookie through the driver but not through executeScript?The session cookie is marked HttpOnly, which is the browser's instruction that page script must not see it. `executeScript` runs inside the page and is subject to that rule. The driver's cookie API is not page script — it asks the browser for the store over the WebDriver protocol, so it returns the cookie and reports the flag through `isHttpOnly()`.
A script read of the page's cookies is the noticeboard in the ward corridor — only what staff chose to display. The driver opens the filing cabinet behind the desk, so it also sees the notes marked staff-only, each with its own date and label.
saying these in an interview costs you the question
- Says getCookies returns every cookie the browser holds
- Thinks the driver reads cookies by evaluating document.cookie
- Claims HttpOnly cookies are invisible to the driver too
- Assumes one deleteAllCookies clears every host's cookies
- Asserts on a cookie count instead of a named cookie