A Playwright test calls page.clock.pauseAt before page.goto and the room page never finishes loading — how should the clock calls be ordered?

This failure is one of the most common ways a `page.clock` test goes wrong, and it reads like an application hang rather than a test defect. ## What pauseAt actually does `page.clock.pauseAt(time)` does two things in one call: it jumps the clock forward to the given moment, firing each due timer at most once on the way, and then it **stops time**. After it returns, nothing in the page moves on its own. No `setTimeout` resolves, no `setInterval` ticks, no `requestAnimationFrame` callback runs. Time only moves again when the test calls `runFor`, `fastForward`, `pauseAt` again, or `resume`. That is exactly the property you want when asserting against a deadline — and exactly the wrong property to hand a page that has not booted yet. ## Why pausing before navigation hangs the load A modern booking page does a surprising amount of its startup on timers: - Debounced hydration and deferred bundles behind a `setTimeout(..., 0)`. - Skeletons and spinners driven by `requestAnimationFrame`. - Retry-with-backoff on the first availability fetch. - Analytics and consent banners on an idle callback. - A one-second interval that renders the "held until" countdown. Under a paused clock none of that ever runs. The page is not slow and not broken; the test froze the mechanism the page uses to make progress. The symptom is a navigation or an assertion that times out with a spinner on screen, which sends people hunting through the app for a bug that does not exist. ## The order that works 1. `await page.clock.install({ time })` — before any navigation, with the start time set slightly *before* the moment under test. 2. `await page.goto(...)` — the page boots on a fake but normally-flowing clock, so bootstrap timers fire as usual. 3. Interact as the test needs: search, open a room, start a checkout. 4. `await page.clock.pauseAt(newDate)` — jump to the moment you want and hold it. 5. Assert. Optionally `runFor(...)` to tick further, or `resume()` to let time flow again. Step 1 matters for a second reason: the documented rule is that if you use `install` at all, it must come before any other clock-related call, because it replaces the page's native `Date`, `setTimeout`, `setInterval`, animation-frame and idle-callback functions. Registering an interval against the real functions and then installing leaves the page holding handles the fake clock knows nothing about, and clearing them afterwards is undefined behaviour. ## Choosing the starting time "Slightly before" is doing real work. Starting at 09:58 for a session that expires at 10:00 gives the page two simulated minutes of ordinary operation to load and settle, then a two-minute jump to the deadline. Starting *at* 10:00 risks the expiry firing during hydration, before the component that renders the banner has mounted — a race that looks like flake and is really a test-authoring bug. ## Symptom to cause | Symptom | Likely cause | |---|---| | Navigation or first assertion times out with a spinner | Clock paused before the page loaded | | Timestamps still show today's real date | `install` called after `goto`, so the page kept the native `Date` | | Deadline behaviour fires during load | Clock installed exactly at the deadline instead of before it | | Page frozen for the rest of the test | `pauseAt` used and `resume` never called | | Poll fires once, not per period | `fastForward` used where `runFor` was meant | ## Scope, and what to check next The clock belongs to the browser context, not the page: `page.clock` and `context.clock` are the same object, and it is delivered as an init script, so it survives navigation and applies to every page and iframe in that context. So the fix is never "install it again on the second page" — if a second surface shows real dates, the install happened after that page's document was created, not on the wrong object. When triaging this in a suite, the questions in order are: was `install` before `goto`; was the start time before the deadline; was the clock left paused into the next step; and is the verb after the pause the one the assertion needs. Four checks, and they cover almost every clock-shaped failure.