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

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