playwright expect.toHaveScreenshot: A snapshot doesn't exist on the first CI

Not specified by the original author.

TL;DR

Playwright refuses to compare against a snapshot that does not exist unless you tell it to create baselines. The first CI run therefore fails every screenshot assertion, which is correct behavior: CI should never silently invent baselines. Generate the snapshots once with --update-snapshots on a machine matching CI's OS, browser, and viewport, commit the files to git, and set CI to fail on missing snapshots instead of creating them.

The query

playwright expect.toHaveScreenshot: A snapshot doesn't exist on the first CI run  -  how to generate

Use this when

• expect.toHaveScreenshot fails with A snapshot doesn't exist on the first CI run
• screenshot specs are new and have never had baselines generated
• CI is configured to run the full suite including visual specs

Not for

• snapshot mismatches where the baseline exists (that is visual drift; review the diff)
• screenshots disabled or skipped in CI (an environment problem, not a baseline problem)
• flaky pixel diffs on existing baselines (stabilize fonts and animations first)

Steps

1. Generate the baselines with --update-snapshots

Run the screenshot specs locally with the update flag. Every missing snapshot is created from the current rendering.

npx playwright test --update-snapshots

Expected output: snapshot PNG files appear next to the specs (or in the configured snapshot path).

2. Match CI's rendering environment before generating

Fonts, OS text rendering, and viewport size all change pixels. Generate on Linux if CI is Linux, with the same viewport the config uses.

// playwright.config.ts
export default defineConfig({
  use: { viewport: { width: 1280, height: 720 } },
});

docker run --rm -v "$PWD":/app -w /app mcr.microsoft.com/playwright:v1.55.0-noble \
  npx playwright test --update-snapshots

Expected output: the baselines are generated in the same rendering environment CI uses.

3. Commit the snapshot files

Snapshots are test fixtures: they belong in git. An untracked snapshot directory is the reason the next CI run fails again.

git add -A && git status --short | grep -i snap | head

Expected output: the snapshot files are tracked and pushed with the specs that reference them.

4. Configure CI to fail on missing snapshots, never create them

Set updateSnapshots to 'none' in CI so a missing snapshot is a loud failure, and a pixel diff is a regression signal rather than an auto-accepted baseline.

export default defineConfig({
  snapshotPathTemplate: '{testDir}/__snapshots__/{testFilePath}/{arg}{ext}',
  updateSnapshots: process.env.CI ? 'none' : 'missing',
});

Expected output: CI fails loudly on missing snapshots and on genuine visual drift, and never writes baselines by itself.

Tool compatibility

• Playwright 1.40 - 1.55
• Chromium, Firefox, or WebKit screenshot assertions

Variant phrasings

• A snapshot doesn't exist on the first CI run
• playwright toHaveScreenshot snapshot missing in CI
• expect.toHaveScreenshot failed: snapshot doesn't exist

Why it happens

Playwright treats a missing baseline as an error rather than an opportunity because auto-creating baselines in CI would bless whatever CI happened to render, including regressions. Baselines must be a deliberate human-approved artifact, generated once and committed, so that every later run compares against intent rather than accident.

Edge cases / pitfalls

• generating on macOS retina and running on CI linux produces false diffs from font rendering and device pixel ratio; generate where CI runs
• dynamic content (timestamps, random ids, live data) must be masked or stubbed or every run diffs
• use toHaveScreenshot with mask locators for animated regions rather than disabling animations globally
• snapshot files are binary: configure git LFS or accept the repo growth deliberately, and review image diffs in PRs like code

Provenance

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

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

Thread query: playwright expect.toHaveScreenshot: A snapshot doesn't exist on the first CI run - how to generate

TL;DR: Playwright refuses to compare against a snapshot that does not exist unless you tell it to create baselines. The first CI run therefore fails every screenshot assertion, which is correct behavior: CI should never silently invent baselines. Generate the snapshots once with --update-snapshots on a machine matching CI's OS, browser, and viewport, commit the files to git, and set CI to fail on missing snapshots instead of creating them.

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.

Install the browsers in CI before the tests run. CI runners start from a clean image every time, so the Playwright browser binaries your laptop has are simply not there - the test run fails at launch with the "Executable doesn't exist" path error. Add the Playwright browser install command as its own step in your CI workflow, before the test step, and cache the browser download directory so later runs do not re-download gigabytes every time. One gotcha: the install must run with the same user and the same browser path the tests use, or the cache lookup misses and you are back to square one.

playwright "Executable doesn't exist at" ms-playwright cache in CI: how to install browsers

Steps

1. Add a browser install step to your CI workflow before the test step: run the Playwright install command for the browsers your config uses (usually chromium, or all three). Keep it as a separate step so its failure is obvious. Expected: the CI log shows browsers downloading and installing, and the path error is gone.

2. Pin the Playwright version in your lockfile and install the matching browsers. A version drift between the npm package and the installed browsers causes cryptic launch failures that look like a different bug. Expected: the installed browser build matches the Playwright package version.

3. Cache the browser directory between CI runs using your provider's cache action keyed on the lockfile hash. This turns a multi-minute download into a cache restore. Expected: a second CI run restores browsers from cache instead of downloading them.

4. If your CI image already ships browsers (some Docker images do), either use that image or point Playwright at the system browsers - but do not do both half-heartedly, or the path lookup misses. Expected: exactly one browser source is configured: downloaded cache or system browsers, not a mix.

5. Verify with a clean run: clear the cache once and watch a full cold install succeed, so you know the pipeline works without a warm cache. Expected: a cold-cache run installs browsers and goes green end to end.

Use this when

• "Executable doesn't exist at" with an ms-playwright path in CI
• CI fails before the first test executes
• you need browsers installed on ephemeral CI runners

Not for this skill when

• browsers installed but crashing on launch (that is a missing system dependency problem - different fix)
• the same error on your laptop (just run the install command locally; no CI involved)

Variant phrasings

playwright install browsers CI

The general form of this task. The error string is the specific symptom; the fix is the install step plus caching.

ms-playwright cache not found

Same error, shorter phrasing. Check the browser path and the installing user before anything else.

Why it happens

Playwright downloads its own patched browser binaries into a cache directory (the ms-playwright folder) on first install. Your laptop has them from when you set the project up; CI runners are fresh machines that only have what your workflow installs. If no workflow step installs the browsers, the first test to launch one fails with the missing-executable error - before any of your test code even runs. Caching the directory between runs avoids paying the download cost on every commit.

Edge cases

• monorepos where the install runs in a different package directory than the tests: the browser path is resolved per project, so run install where the tests run
• self-hosted runners with a persistent disk: you can install once and skip the CI step, but document it - the next person to rebuild the runner will hit this error
• browser install needs system dependencies too on bare Linux images: the install command has a flag for OS deps, and without them the browsers install but will not launch

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6zO3Akmgm-9q1rj_shPfg

Resolved from the public thread: https://vectle.com/posts/pst6zO3Akmgm-9q1rj_shPfg

Thread query: playwright "Executable doesn't exist at" ms-playwright cache in CI: how to install browsers

TL;DR: