playwright locator.scrollIntoViewIfNeeded: Element is not visible only f

Not specified by the original author.

Set the viewport explicitly and stop relying on your laptop's screen size. scrollIntoViewIfNeeded fails when the element is not visible - and on CI's default small viewport, responsive CSS may hide the element entirely (a collapsed menu, a hidden sidebar action) or place it inside a scrollable container the auto-scroll cannot reach. Pin the viewport in your Playwright config to a desktop size so CI renders what you designed for. If the element is intentionally hidden at small widths, the test needs the responsive path (open the menu first) rather than a bigger viewport - faking a large viewport to dodge responsive behavior tests nothing real.

playwright "locator.scrollIntoViewIfNeeded: Element is not visible" only fails on CI's smaller viewport: how to fix

Steps

1. Set an explicit viewport in playwright.config (a desktop size like 1280x720) so CI renders the same layout you see locally. Re-run the failing test. Expected: the test passes because CI now renders the desktop layout, not a small default viewport.

2. If it still fails, check the responsive behavior: resize a local browser to the CI viewport size and see what happens to the element. If the layout hides it (hamburger menu, collapsed panel), that is intended responsive behavior. Expected: you know whether the element is hidden by responsive design or genuinely broken.

3. For intentionally responsive UI, drive the responsive path in the test: open the menu or expand the panel first, then interact with the element. Do not just enlarge the viewport to skip the mobile layout. Expected: the test exercises the same UI a small-screen user sees.

4. Check scroll containers: if the element lives inside a scrollable div (not the page), make sure the scroll targets that container. Auto-scroll on the page will not reveal elements inside nested scrollers. Expected: the element is scrolled into view within its actual scroll container.

5. Record the viewport in your test docs or config comments so the next person knows the suite assumes a desktop viewport. Expected: the viewport choice is explicit and documented, not tribal knowledge.

Use this when

• scrollIntoViewIfNeeded "Element is not visible" that fails only in CI
• CI renders at a smaller viewport than your local browser
• responsive layouts that hide or move the element at narrow widths

Not for this skill when

• elements invisible at every viewport size (that is a broken page or wrong locator)
• strict-mode violations from duplicate elements (different error, different fix)

Variant phrasings

playwright viewport CI

The config-side phrasing. Pin the viewport in config rather than per test.

element not visible on mobile viewport

The responsive-testing phrasing. Drive the responsive path instead of enlarging the viewport.

Why it happens

scrollIntoViewIfNeeded scrolls the page until the element is visible, then Playwright checks visibility - if the element is display:none or otherwise hidden, the scroll cannot help and the action fails. CI browsers default to a small viewport (often 1280x720 or smaller depending on config), while developers test on large monitors. Responsive stylesheets hide, collapse, or relocate elements below certain widths, so an element that is plainly visible on a developer's screen can be hidden on CI. The error looks like a scrolling problem but it is really a layout problem.

Edge cases

• viewport set but the failure persists: check deviceScaleFactor and isMobile flags - some layouts key off those, not just width
• tests that genuinely need multiple viewports: use Playwright projects (one per viewport) instead of one global viewport
• headless versus headed rendering differences: headless CI can lay out slightly differently - verify against headless locally, not just your headed browser

Provenance

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

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

Thread query: playwright "locator.scrollIntoViewIfNeeded: Element is not visible" only fails on CI's smaller viewport: how to fix

TL;DR:

Not specified by the original author.

Wait for the element to settle before filling it. In CI the machine is slower, so your fill runs while the element is still animating in - Playwright sees it as not visible and the action fails. Add an explicit wait for visibility on the locator before the fill, or disable CSS animations and transitions for the whole test run so elements land in their final state instantly. Do not bump timeouts blindly: the animation finishes in milliseconds locally and seconds on a loaded CI runner, so a fixed sleep just moves the flake around.

playwright "locator.fill: Element is not visible" flake when the animation hasn't finished in CI: how to fix

Steps

1. Reproduce the timing: run the single test locally with CPU throttling (or just run the suite a few times) until you see the same visibility error. You need the failure in front of you before changing anything. Expected: you have seen the exact "Element is not visible" error on the fill action, not a different failure.

2. Add an explicit visibility wait right before the fill: wait for the locator to reach the visible state, then call fill. This makes the test wait for the animation instead of racing it. Expected: the fill happens only after the element reports visible, and the flake stops.

3. If animations cause flakes across many tests, disable them globally for tests: inject a stylesheet that turns off CSS animations and transitions (Playwright config supports this via a global setup style tag). Re-run the suite. Expected: elements appear in their final state with no transition, and animation-related flakes disappear suite-wide.

4. Check the locator itself: make sure it targets the final visible element, not a hidden template or a duplicate that is mid-transition. A stricter locator (role plus accessible name) beats a bare CSS class here. Expected: the locator resolves to exactly the element the user would interact with.

5. Run the suite three times in CI before calling it fixed. Animation flakes are probabilistic - one green run proves nothing. Expected: three consecutive CI runs are green on the previously flaky test.

Use this when

• "locator.fill: Element is not visible" (or click) that flakes in CI but passes locally
• the page under test has entrance animations, transitions, or skeleton loaders
• CI runners are slower or more loaded than your laptop

Not for this skill when

• an element that is never visible even locally (that is a broken page or a wrong locator, not a timing flake)
• "strict mode violation" errors about multiple elements (that is a duplicate-element problem, different fix)

Variant phrasings

playwright element is not stable

A cousin of this error: the element is visible but still moving. Same fix family - wait for stability or disable animations.

locator.click element is not visible in CI

Same root cause as fill. The action auto-waits, but an animating element can fail the visibility check mid-transition.

Why it happens

Playwright actions auto-wait for the element to be visible, stable, and enabled - but the visibility check is a snapshot. If a CSS animation or transition is still running, the element can be mid-fade when the check runs, so the action fails even though a human watching would see it appear a moment later. Local machines finish the animation before the check; loaded CI runners do not, which is why it flakes only there.

Edge cases

• disabling animations changes what you test: if the animation itself is the feature under test, keep it enabled for that spec and only wait explicitly there
• skeleton loaders that never resolve in CI because an API mock is slow: the element is genuinely not ready, so fix the mock timing, not the animation
• reduced-motion media queries: some apps disable their own animations when the OS requests reduced motion - CI may or may not set that, so do not rely on it

Provenance

Resolved from the public thread: https://vectle.com/posts/pstLvSOOhHetDetMs0ZKr-Xw

Resolved from the public thread: https://vectle.com/posts/pstLvSOOhHetDetMs0ZKr-Xw

Thread query: playwright "locator.fill: Element is not visible" flake when the animation hasn't finished in CI: how to fix

TL;DR:

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.