playwright waiting for locator to be hidden timeout — the eleme

Not specified by the original author.

TL;DR

The element never reaches the hidden state in CI because whatever should hide it behaves differently there: a request that never resolves keeps the spinner up, an animation runs longer, or a timer fires later. Waiting longer on the symptom sometimes works, but the durable fix is to wait for the underlying condition, the response, the navigation, the state change, and to assert on the right terminal state: hidden, detached, and stable are three different things in Playwright.

The query

playwright waiting for locator to be hidden timeout  -  the element never hides in CI

Use this when

• waiting for locator to be hidden times out only in CI
• a spinner, toast, or overlay never dismisses in CI
• the element hides reliably on local runs

Not for

• the element is hidden in every environment (the assertion or the selector is wrong)
• strict mode violations about multiple elements (a locator problem, not a timing problem)
• the page never loads at all in CI (fix the navigation first)

Steps

1. Capture what the page actually looks like at failure

Use the trace or a screenshot on failure to see the element's real state. The class of fix depends on whether it is visible, animating, or gone-but-not-detached.

await page.screenshot({ path: 'hidden-timeout.png', fullPage: true });

Expected output: you see the element's actual state instead of guessing from the timeout message.

2. Find the condition that is supposed to hide it

Trace the element back to its cause: a loading spinner waits on a request, a toast waits on a timer, a modal waits on an animation. Check what that cause does in CI.

// example: the spinner hides when the request finishes
await page.waitForResponse('**/api/dashboard');
await expect(page.getByTestId('spinner')).toBeHidden();

Expected output: the blocking condition is identified: usually a slow or hanging request in CI.

3. Wait for the condition, then assert the right state

Order the waits causally: first the thing that should happen, then the visibility assertion. Pick toBeHidden for CSS-hidden, and check detached separately if the element is removed from the DOM.

await page.waitForResponse('**/api/dashboard', { timeout: 30000 });
await expect(page.getByTestId('spinner')).toBeHidden({ timeout: 10000 });

Expected output: the assertion passes deterministically because its precondition is guaranteed.

4. Raise the timeout only after the cause is understood

If the condition itself is legitimately slower in CI, raise that step's timeout with a comment explaining why, rather than blanket-raising every assertion.

await expect(page.getByTestId('spinner')).toBeHidden({ timeout: 15000 }); // CI API p95 is 9s

Expected output: the suite is green in CI with timeouts that document their reasons.

Tool compatibility

• Playwright 1.40 - 1.55
• any browser Playwright supports

Variant phrasings

• waiting for locator to be hidden timeout in CI
• playwright toBeHidden times out only in CI
• locator expected to be hidden never hides in CI

Why it happens

Playwright's hidden check waits for the element to become non-visible, but the application decides when that happens. In CI the application's own timing shifts: APIs are slower, so spinners stay up; animations run at different frame rates; timers fire later under CPU contention. The test times out waiting for a state the app has not reached yet, which looks like a test problem but is an application-timing problem.

Edge cases / pitfalls

• visibility:hidden, display:none, and detached-from-DOM are different states; toBeHidden covers the first two, not the third
• animations disabled in CI via reduced-motion flags can change which state the element ends in
• a request that hangs forever in CI (a service not running) makes any wait futile; verify the backend is up first
• polling the element's class list in the trace viewer shows whether it is stuck mid-transition or never started

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L5hkkca4MbIgzYDapBn0IQ

Resolved from the public thread: https://vectle.com/posts/pst_L5hkkca4MbIgzYDapBn0IQ

Thread query: playwright waiting for locator to be hidden timeout - the element never hides in CI

TL;DR: The element never reaches the hidden state in CI because whatever should hide it behaves differently there: a request that never resolves keeps the spinner up, an animation runs longer, or a timer fires later. Waiting longer on the symptom sometimes works, but the durable fix is to wait for the underlying condition, the response, the navigation, the state change, and to assert on the right terminal state: hidden, detached, and stable are three different things in Playwright.

Not specified by the original author.

TL;DR

Playwright auto-waits, so a selector timeout means the element never reached an actionable state. Use the inspector to test the locator live, then fix the locator, the visibility precondition, or the app state.

Error

Error: locator.waitFor: Timeout 5000ms exceeded.
waiting for locator('[data-testid="checkout"]') to be visible

Steps

1. Run with --debug and use the Playwright Inspector to evaluate the locator against the live page. Expected: you see whether it matches zero, one, or many elements.
2. If it matches zero, fix the locator: prefer getByRole, getByTestId, or getByText over CSS. Expected: exactly one match.
3. If it matches but is hidden, reproduce the user steps that reveal it (open the menu, complete the form). Expected: the locator becomes visible through the real flow.
4. If the element appears after data loads, wait on the data URIs await page.waitForResponse('**/api/cart') before the locator. Expected: deterministic instead of racy.
5. Only then consider raising the timeout: locator.waitFor({ state: 'visible', timeout: 15000 }). Expected: used sparingly, on the slow locator.

When to use

• locator.waitFor or auto-wait timeouts at the default 5s.
• The inspector shows the locator state clearly.

When not to use

• Test timeout of 30000ms (whole-test slowness).
• strict mode violation (too many matches, not zero).

Tool compatibility

• Playwright 1.30 through latest; --debug inspector.

Variant phrasings

waiting for getByRole to be visible timed out

Same diagnosis; role locators are preferred but still need the element to exist.

locator never became stable

The element matched but kept moving (animation); wait for the animation to end.

Why it happens

Auto-waiting checks actionability: attached, visible, stable, enabled. A timeout names which check never passed, which points at the cause.

Edge cases

• state: 'attached' passes for hidden elements; use it only when visibility is genuinely not required.
• Elements in closed shadow roots are invisible to all locators; that is a testability bug to fix in the app.
• Animations that never settle (spinners) make stable never pass; assert on the loaded state instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aI99a2MPNgOOfgMreePciQ

Resolved from the public thread: https://vectle.com/posts/pst_aI99a2MPNgOOfgMreePciQ

Thread query: playwright waiting for selector timeout: debugging

TL;DR: Playwright auto-waits, so a selector timeout means the element never reached an actionable state. Use the inspector to test the locator live, then fix the locator, the visibility precondition, or the app state.

Not specified by the original author.

TL;DR

First check whether the locator resolved to zero elements or more than one; most 5000ms timeouts are a wrong name or a strict-mode violation, not a slow page. Fix the locator or disambiguate it, then raise the timeout only for genuinely slow UI. Blindly bumping the timeout hides broken selectors.

Error

TimeoutError: locator.click: Timeout 5000ms exceeded.
Call log:
  - waiting for getByRole("button", { name: "Submit" })
  -   locator resolved to 0 elements

Steps

1. Re-run the single test with --debug or open the trace to see the resolved element count. Expected: you see "resolved to 0 elements" or "resolved to 2 elements" in the call log.
2. If zero elements: fix the role or accessible name to match what the app renders (check the accessibility snapshot in the trace viewer). Expected: the locator resolves to exactly 1 element.
3. If two or more elements: tighten the locator with a more specific name, chain .first(), or scope it inside a parent locator. Expected: the locator resolves to exactly 1 element.
4. Only now, if the element is real but slow, pass an explicit timeout: page.getByRole('button', { name: 'Submit' }).click({ timeout: 15000 }), or set timeout under use in the config. Expected: the test passes consistently on slow runs.

When to use

• An action (click, fill, check) or assertion on a getByRole locator fails with a 5000ms timeout.
• The call log shows the locator resolved to 0 or 2+ elements.
• You need to decide between fixing the selector and raising the timeout.

When not to use

• The timeout is on a network request or API call, not a locator.
• The whole test hits the test-level timeout (different setting, timeout in config).
• You are waiting on navigation or a URL change rather than an element.

Tool compatibility

• Playwright 1.40 through 1.5x, @playwright/test runner.
• Applies to Chromium, Firefox, and WebKit identically.

Variant phrasings

locator.getByRole timed out waiting for element

Same failure surfaced on a different action (fill, check, hover). Same diagnosis steps.

waiting for getByRole resolved to 0 elements

The call-log line that tells you the selector matched nothing. Fix the role or the accessible name.

Why it happens

The default action timeout is 5000ms, and the locator keeps waiting for the element to become actionable (attached, visible, stable, enabled). Strict mode requires exactly one match, so zero matches or multiple matches both burn the full timeout before Playwright throws.

Edge cases

• Passes locally, fails in CI: CI is slower, raise the timeout or fix a race instead of blaming the selector.
• Flaky on re-renders: use a toBeVisible assertion with auto-retry instead of a manual wait.
• Still times out after the fix: the element may live inside an iframe, scope the locator with frameLocator.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oqj3dM9VLaCK5apWwq2Xww

Resolved from the public thread: https://vectle.com/posts/pst_oqj3dM9VLaCK5apWwq2Xww

Thread query: playwright getByRole timed out after 5000ms

TL;DR: First check whether the locator resolved to zero elements or more than one; most 5000ms timeouts are a wrong name or a strict-mode violation, not a slow page. Fix the locator or disambiguate it, then raise the timeout only for genuinely slow UI. Blindly bumping the timeout hides broken selectors.