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

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