In Selenium, what does driver.getCurrentUrl() return after a submitted claim form redirects to a confirmation page?

## What the call actually reads `driver.getCurrentUrl()` is not a memory of what your test asked for. It sends the W3C WebDriver **Get Current URL** command, `GET /session/{sessionId}/url`, and the remote end answers with the serialised document URL of the **top-level browsing context**'s active document — the address the tab is displaying at that instant. Selenium keeps no record of the string you handed to `get()` or `navigate().to()`, so there is nothing to compare against except the live state of the browser. For a claim intake suite that matters immediately, because the submit step almost never leaves the tab where it started. ## Why it differs from the URL you requested Several ordinary things change the address between the request and the read: - **Server redirects.** `POST /claims` answers with a redirect to `/claims/CLM-8842/confirmation`; the tab follows it, and `getCurrentUrl()` reports the destination rather than the form's action. - **Generated identifiers.** The claim reference in that path did not exist when the test started, so no literal written into the test can ever match it. - **Appended query parameters.** A locale, campaign or tracking parameter the server adds on the way comes back in the string too. - **URL normalisation.** Ask for `https://claims.example.test` and you get `https://claims.example.test/` back — the empty path is serialised as a slash. - **Later navigation.** If the page moves the address on after loading, a later read returns the later address; the value is only true for the moment it was taken. | What the test passed | What `getCurrentUrl()` returns afterwards | |---|---| | `https://claims.example.test` | `https://claims.example.test/` | | `https://claims.example.test/intake`, then a redirect | `https://claims.example.test/intake/step-1` | | The intake form's action, submitted | `https://claims.example.test/claims/CLM-8842/confirmation` | ## `getTitle()`, the companion read `driver.getTitle()` sends the **Get Title** command, `GET /session/{sessionId}/title`, and returns the document title of the same top-level context — the value the page's `<title>` element supplies. Two practical notes: - It reads the title as the browser currently computes it, so a page that rewrites its title after loading can return different values at different moments in the same test. - A title is application copy. It changes for reasons that have nothing to do with navigation — a marketing edit, a translation, a trailing product name — which makes it a weaker landing assertion than a path segment. ## Both are scoped to the top-level context The WebDriver protocol defines both commands against the **current top-level browsing context**, not against whatever the session happens to be switched into. After the session switches into an iframe embedded in the intake page, `getCurrentUrl()` still reports the page's own address and `getTitle()` still reports the page's own title; neither tells you anything about the frame's document. Reading a frame's own source address needs a different route entirely. ## Assertion patterns that hold up 1. **Assert on a stable segment, not the whole string.** Check that the current URL contains `/confirmation`, or that it matches a pattern such as `/claims/[A-Z]{3}-\d+/confirmation`, instead of demanding equality with a literal. 2. **Capture, then reuse.** Read `getCurrentUrl()` once after the submit and keep it: that captured address is how you return to the confirmation later with `navigate().to(...)`, and in some applications it is the only place the claim reference appears in machine-readable form. 3. **Assert on content when the URL is not the contract.** If one address can serve several states — a wizard that keeps `/intake` across every step — an element on the page is the stronger check and the URL is a weak proxy for it. ## A point-in-time read, not a wait Neither call blocks. `getCurrentUrl()` returns whatever is current the moment it executes, so calling it too soon after clicking Submit can return the intake form's address rather than the confirmation's, and the assertion then fails on timing rather than on behaviour. The remedy is Selenium's waiting API, which is a separate mechanism with its own topic; the point here is that these two reads carry no waiting of their own and are never a substitute for one. ## Where the pair earns its place in a claim intake test - Straight after `get()`, to prove the suite is pointed at the environment it thinks it is pointed at. - After a submit, to capture the confirmation's address so a later step can revisit it. - After `navigate().back()`, to prove the tab really moved rather than silently staying put. - In a failure message, where "expected /confirmation but was /intake" says far more to the next reader than "element not found".