playwright expect().toBeVisible() failed: element never appeared

Not specified by the original author.

TL;DR

toBeVisible auto-retries for the assertion timeout (default 5s), so a failure means the element never became visible in that window. Confirm the locator matches something attached to the DOM first, then fix the app state or timing that keeps it hidden. Raising the timeout is the last resort, not the first.

Error

Error: expect(locator).toBeVisible() failed
Locator: getByRole('dialog', { name: 'Confirm delete' })
Expected: visible
Received: hidden

Steps

1. Temporarily change the assertion to toBeAttached() and re-run. Expected: this tells you whether the locator is wrong (still fails) or the element exists but stays hidden.
2. If not attached: fix the locator using the trace viewer's DOM snapshot. Expected: toBeAttached() passes.
3. If attached but hidden: drive the UI state that reveals it (click the opener, wait for the API response with waitForResponse), or check for a CSS or overlay issue in manual reproduction. Expected: the element becomes visible when you reproduce by hand.
4. If the UI is just slow, extend the assertion: await expect(dialog).toBeVisible({ timeout: 10000 }). Expected: the assertion passes on slow runs.

When to use

• expect(locator).toBeVisible() fails after the full assertion timeout.
• A dialog, toast, or dropdown never shows up in the test.
• You need to separate "wrong locator" from "right locator, hidden element".

When not to use

• The element is visible but a click is intercepted (that is a pointer-events problem, not visibility).
• An action like click() times out rather than an assertion.
• The element is inside an iframe (scope with frameLocator first).

Tool compatibility

• Playwright 1.40 through 1.5x, @playwright/test runner.
• Web-first assertions (toBeVisible, toBeAttached, toBeHidden) all share the same retry behavior.

Variant phrasings

expect locator toBeVisible timed out after 5000ms

Same failure with timeout wording. Same steps: check attached first.

element is not visible in playwright assertion

Usually the same toBeVisible failure. Confirm the locator matches a node before debugging visibility.

Why it happens

toBeVisible requires a non-empty bounding box and no visibility: hidden. Common causes are unmet app state (the dialog never opened, the data never loaded), the element rendering at zero size or off-screen, or a wrong locator matching a hidden duplicate node.

Edge cases

• The locator matches a hidden duplicate while the visible node has a different name: tighten the name or scope the locator.
• Mid-animation: the element is transitioning, assert on a stable parent or wait for the animation to settle.
• toBeVisible passes but the click misses: an overlay is intercepting pointer events, a different failure mode.

Provenance

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

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

Thread query: playwright expect().toBeVisible() failed: element never appeared

TL;DR: toBeVisible auto-retries for the assertion timeout (default 5s), so a failure means the element never became visible in that window. Confirm the locator matches something attached to the DOM first, then fix the app state or timing that keeps it hidden. Raising the timeout is the last resort, not the first.

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.

Figure out whether CI is slow or the button is really missing. A getByRole timeout on CI-only usually means one of two things: the page takes longer to reach the state where the button appears (slow network, slow backend, cold cache), or the button never appears in CI because the environment differs (feature flag, seed data, auth state). Turn on tracing for the failing test, watch where the time goes, and only then decide: raise the timeout if the button does appear eventually, fix the environment if it never does. Raising the timeout on a button that never appears just makes the suite slower and still red.

playwright "waiting for getByRole('button') to be visible" timeout only on CI: debugging

Steps

1. Capture a trace of the failing CI run: enable tracing (retain on failure is enough) and download the trace artifact. Open it and watch the timeline around the failing wait. Expected: you can see exactly what the page looked like while Playwright was waiting - spinner, blank page, or the button already there.

2. Check whether the button appears at all in the trace. Scrub to the end of the timeout: if the button is visible in the final screenshot, CI is just slow; if it never appears, the environment is wrong. Expected: you have classified the failure: slow (button eventually shows) versus missing (button never shows).

3. If slow: raise the timeout for this wait or mark the test slow on CI rather than changing the locator. Also check what the button waits on - a slow API response in CI is the usual culprit, and the fix may belong in test data setup, not the test. Expected: the test passes with the higher timeout and the extra time is explained by a known slow step.

4. If missing: diff the CI environment against local - feature flags, seeded data, auth session, base URL. The button is probably gated behind something CI does not set up. Expected: you found the environmental difference and the button appears once it is fixed.

5. Add the missing setup (or the documented timeout) to the shared fixtures so the next test hitting this page does not rediscover the same problem. Expected: the fix lives in shared setup, not copy-pasted into one test.

Use this when

• getByRole (or any locator) wait-for-visible timeouts that happen only in CI
• you need to tell "CI is slow" apart from "CI is different"
• a button gated behind async work like API calls or auth

Not for this skill when

• "strict mode violation: resolved to N elements" (that means the locator matches too much, not too little)
• a button that never appears locally either (that is an app bug - file it against the app)

Variant phrasings

playwright getByRole timeout

Same error without the CI-only qualifier. The debugging path is identical, but CI-only adds the environment-diff step.

waiting for locator to be visible exceeded timeout

The generic form. getByRole is just the locator flavor; the slow-vs-missing classification applies to all of them.

Why it happens

getByRole queries the accessibility tree, so it only matches when the button is actually exposed to assistive tech - after render, after data loads, after any gating logic runs. CI stretches every one of those steps: slower CPUs render later, colder caches fetch later, and CI-specific config (flags, seed data) can gate the button entirely. The timeout message looks identical for "slow" and "missing", which is why the trace check comes before any fix.

Edge cases

• the button appears in the trace but the test still times out: check for overlapping elements or pointer-events issues - visible to the accessibility tree is not the same as clickable
• CI runs against a preview deployment with different data URIs seed the data the button depends on, or the timeout will return
• raising timeouts globally in playwright config: fine as a diagnostic, but a suite-wide timeout bump hides real slowdowns - scope it to the slow test

Provenance

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

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

Thread query: playwright "waiting for getByRole('button') to be visible" timeout only on CI: debugging

TL;DR: