spinner-waiter: an in-flight navigation counts as loading

[mmkal]

Spinner-waiter's rule is "if the app is visibly loading, wait longer". Right after a cross-server hop (an OAuth popup landing on a cold auth page), the document has committed but hasn't fired load — it's still fetching and rendering its UI client-side. The app can't draw a spinner yet, but the browser's tab spinner is on. Today that reads as "no spinner" and fast-fails in 1ms, which is why ../iterate's OAuth-popup specs still carry { timeout: 15_000 } on popup actions even after popups auto-wrap.

After this, a document that hasn't finished loading (document.readyState !== "complete", or no execution context yet while a navigation commits) counts as loading UI — bounded by the same grace period and spinnerTimeout as an app spinner, and considered by the "loading finished without the element" bail-out too:

const popup = await popupPromise;            // auto-wrapped
await popup.getByTestId("email-login-button").click();
// before: TimeoutError 1ms — the auth page had committed but was still rendering
// after: waits through the load like it would a spinner, then clicks
await popup.getByRole("button", { name: "Allow access" }).click(); // no timeout needed

Two findings from instrumenting, recorded in tasks/complete/2026-08-18-spinner-waiter-navigation-loading.md:

• Playwright's locator queries (isVisible, count) already block until a pending navigation commits, so the "waiting for a slow server response" phase needs nothing from us. A first cut tracked pending main-frame requests; it never fired and is gone. The reachable window is post-commit, pre-load — the spec for it fast-fails at 1ms when the check is disabled, so it's genuinely load-bearing.
• Known limitation, out of scope: an action that initiates a slow navigation (clicking a link to a cold server) is bounded by its own actionTimeout — Playwright waits for the navigation inside the action, after spinner-waiter has let it through.

Not touched: page.waitForEvent("popup", { timeout }) in iterate — an event wait middlewright never sees; the fix there is product loading UI on the Sign-in button.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes core spinner-waiter timing and loading detection for all wrapped locator actions; behavior is well-specified but affects a sensitive test path (timeouts and OAuth popups).

Overview
spinnerWaiter now extends the “visibly loading” rule beyond app spinners: a document that has committed but not finished loading (readyState !== "complete"), or a navigation still committing (no execution context), is treated like a spinner—same grace period and spinnerTimeout, and the same early bail-out when loading ends without the target element.

That fixes OAuth-style popups that arrive already navigating to a cold auth page: there is no app spinner yet, but the tab is still loading; actions used to hit the 1ms no-spinner fast-fail instead of waiting through load.

Implementation adds loadingVisible / pageIsNavigating and wires them into the initial loading check and waitForReadyWhileSpinning. README documents the behavior; two specs cover success while the document is still loading and fast-fail once navigation is complete without the expected control.

^{Reviewed by Cursor Bugbot for commit c5feb42. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@39

commit: c5feb42