Playwright 1.62 for QA

Three features in 1.62 aim straight at the noise that makes suites lie: isolated retries, an opt-out for auto scrolling, and clipboard isolation in headless mode.

Isolated retries: retry without the neighbors

One config line turns retries from a reflex into a controlled experiment:

export default defineConfig({
  retries: 2,
  retryStrategy: 'isolated',
});

1. Fail during the run. A test fails while the suite is running in parallel as usual; nothing retries yet.
2. Retry deferred. The retry is queued instead of firing immediately next to the workers that were hammering the machine.
3. End of run, single worker. All queued retries execute sequentially in one worker, with no parallel neighbors competing for resources.
4. Verdict. A pass on the quiet machine is strong evidence of neighbor noise; a repeat failure is strong evidence of a real bug worth a ticket.

• Why inline retries lie. Retrying immediately on a busy machine re-creates the exact contention that flaked the test in the first place, so the retry often reproduces the flake instead of ruling it out.
• Default unchanged. Immediate inline retry stays the default until you opt in, so adding retryStrategy: 'isolated' to your flakiest project is a low-risk, one-line, fully reversible experiment.

The two quiet stability fixes

• scroll: "auto" or "none" on actions. Actions auto-scroll the target into view by default. When that scroll fights a sticky header or a virtualized list, pass scroll: "none" to opt out and control the scrolling yourself.
• Clipboard isolated in headless mode. navigator.clipboard tests no longer read or clobber the host machine clipboard, which protects the CI machine and your laptop equally when copy-paste specs run.

Next up: the Passkeys tab, where virtual authenticators turn WebAuthn login into a spec you can actually write.

Passkey login flows stop being the untestable corner of the suite. Playwright 1.62 adds a Credentials API that spins up virtual WebAuthn authenticators per browser context, so the login your users actually perform becomes a spec you can write, run, and reuse like any other.

Virtual authenticators, per context

The whole setup is a fresh context plus two credentials calls.

const context = await browser.newContext();
await context.credentials.create('example.com', {
  id: credentialId,
  userHandle,
  privateKey,
  publicKey,
});
await context.credentials.install();

• The virtual authenticator lives on the BrowserContext. Passkey state is scoped the way cookies are: each context carries its own authenticator, so credential material stays scoped per context across parallel workers.
• create() registers the passkey material. You hand it the site plus the credential parts (id, userHandle, privateKey, publicKey), and the context now knows about that passkey.
• install() arms it. Once installed, the virtual authenticator answers the app's WebAuthn challenge, and the passkey button that used to dead-end an automated run now completes the login.

Passkeys in storage state

• The credentials storage state option persists passkeys. Save state after a passkey login and the credential material is captured for reseeding, so a fresh context can start already enrolled.
• It is the pattern you already run for cookies. Log in once in a setup project, save storage state, and every dependent test starts authenticated. The passkey simply joins the saved state instead of forcing a fresh ceremony per test.
• Why this matters. Until now, teams either skipped passkey coverage or hacked around it with manual workarounds, which meant the primary auth path shipped untested. That gap closes here.

A pragmatic first passkey spec

1. In a setup project, call credentials.create() with your test credential material, then credentials.install() to arm the authenticator.
2. Drive the app's passkey registration flow once with that context, so the app enrolls the virtual credential.
3. Save storage state with the credentials option, so the passkey persists alongside the cookies.
4. In a dependent project, load that state and assert one protected page renders. That single check tells you passkey auth holds before you invest in deeper flows.

Auth sorted. Next, the Components tab: the new stories-and-galleries model that points your existing locator skills at a much faster layer.

Component tests that reuse your e2e muscle memory: the same locators, the same web-first assertions, pointed at a mounted component instead of a deployed app. If your team writes Playwright e2e today, the new concepts are the story, the gallery, and the mount line; everything after mount is familiar.

Stories, galleries, and mount

• Stories wrap components in specific scenarios. A story pins a component into one concrete state, so instead of testing "the Expandable" in the abstract, you test "the Expandable in its Stateful scenario".
• Galleries collect stories. The gallery is the page that gathers your stories, which gives the runner a stable place to navigate.
• fixtures.mount() ties it together. mount() navigates to the gallery, mounts a story by its ID, and returns a scoped locator. Everything after that line is standard Playwright.

test('click should expand', async ({ mount }) => {
  const component = await mount('components/Expandable/Stateful');
  await component.getByRole('button').click();
  await expect(component.getByTestId('expanded')).toHaveValue('true');
});

Where component tests fit for a QA team

• It is the fastest layer that still renders real UI. No full deployment behind it, yet a real component renders and responds in a real browser, so feedback arrives in seconds rather than after a journey's worth of setup.
• It catches visual and state bugs before e2e does. A widget stuck in the wrong state fails here in isolation, instead of three steps deep into a checkout journey where the root cause hides.
• One skill set across layers. Because the locators and web-first assertions are identical to e2e, nobody maintains a second mental model, and component specs stay readable to anyone who reads your e2e suite.
• Split coverage deliberately. Keep business-flow coverage in e2e, where the journey is the point, and push widget states down into stories, where they run fast and fail with a precise finger pointed at the component.

That is the component story. Next, the DX + API tab: cancelling stuck operations with AbortSignal, WebP snapshots, and Reporter.preprocess() filtering.

None of these headline a release on their own; together they remove a dozen daily papercuts from writing, running, and maintaining tests. This is the batch you feel one sprint after upgrading.

Cancel operations with AbortSignal

Most operations now accept a signal option, wired to the same AbortController the web platform already gave you.

const controller = new AbortController();
setTimeout(() => controller.abort(), 1000);
await page.getByRole('button', { name: 'Submit' }).click({ signal: controller.signal });
await expect(page.getByText('Done')).toBeVisible({ signal: controller.signal });

• Standard web pattern. Plain AbortController, no custom Playwright cancellation API to learn, wrap, or unlearn later.
• Broad coverage. The signal option works on actions, navigations, waits, and assertions, so the slow thing you want to bail out of almost certainly takes it.
• One controller, many operations. The example shares a single signal across a click and an assertion; one abort() stops everything still listening.

Quarantine as code: Reporter.preprocess()

Reporters get a hook that reshapes the run before a single worker starts.

class MyReporter {
  async preprocess({ config, suite, testRun }) {
    for (const test of suite.allTests()) {
      if (shouldSkip(test))
        testRun.skip(test);
    }
  }
}

• Runs after config resolution. By the time preprocess() fires, the config is resolved and the full suite is in hand, so decisions can use both.
• Skip or exclude via TestRun. Tests are marked skipped or excluded through the TestRun object; testRun.skip(test) is the whole trick in the example.
• Policy becomes code. Quarantine lists, flake exclusion, and shard policies become reporter code you can review and version, instead of grep gymnastics bolted onto the run command.

WebP snapshots and the rest

Visual comparisons speak lossless WebP by naming the snapshot .webp; standalone screenshots add a quality knob (100 is lossless, lower values are lossy).

await expect(page).toHaveScreenshot('homepage.webp');
await page.screenshot({ path: 'homepage.webp', quality: 50 });

• Merge-files grouping. One config line, reporter: [['html', { mergeFiles: true }]], enables Merge-files grouping in the HTML reporter.
• API perf visibility. apiResponse.timing() returns resource timing for API responses, so perf checks can ride along inside the API tests you already run.
• Element-scoped waits. locator.waitForFunction() waits until a function returns truthy on the matching element.
• Functions as arguments. page.evaluate(), page.addInitScript(), and browserContext.addInitScript() now accept functions as arguments.
• Auto-scroll opt-out. Actions take a scroll option, "auto" or "none", so you can opt out of automatic scroll-into-view.
• Clipboard isolation. In headless mode, navigator.clipboard tests no longer read or overwrite the host machine clipboard.

Those are the papercuts. The structural change is bigger: the MCP server and the CLI now ship inside the runner itself, and that is the whole next tab, MCP + agents.

The line between your test runner and your AI tooling just got shorter: the agent plumbing now ships in the box you already install.

MCP server and CLI, bundled

The release notes put it in one sentence: "Playwright now bundles the Playwright MCP server and playwright-cli, runnable via npx playwright mcp and npx playwright cli."

• Zero extra install. Any repo with @playwright/test already carries the MCP server; there is no separate package to add.
• The standalone package survives. @playwright/mcp still exists and still works, so existing wiring keeps running.
• Agents point at one command. Agent setups, Copilot or Claude Code, can point straight at npx playwright mcp.

npx playwright mcp
npx playwright cli

Wiring an agent to it is three moves.

1. Confirm the repo is on @playwright/test 1.62; the MCP server travels with it.
2. Run npx playwright mcp, nothing extra to install.
3. Point the agent setup, Copilot or Claude Code, at that command.

Companion release: the standalone server

Alongside the runner, the standalone Playwright MCP server reaches 0.0.79 with its own set of upgrades.

• Codegen in three more languages. Codegen expands to Python, Java, and C#: the agent browses the app, then emits tests in those languages.
• WebP screenshots here too. The server gains WebP screenshot support, the same format the runner's snapshots just adopted.
• Configurable settle delay. The settle delay for action timeouts is now configurable.
• Setup unchanged. npx @playwright/mcp@latest still starts it; since 1.62, plain npx playwright mcp does the same job.
• Its own cadence. The standalone server ships on a separate release schedule from the runner; 0.0.79 is the companion to this runner release.

What this unlocks for QA agents

• Reviews that verify, not trust. Our recommended pattern: a review skill launches npx playwright mcp and checks that a locator in the diff resolves against the live app, instead of taking the author's word for it; the QA code-review skill build walks that exact setup.
• Tests for teams not on TypeScript. With codegen in Python, Java, and C#, an agent can walk the flow once and hand a Java or C# team tests in the language their framework already speaks.
• One less step for 1.62 repos. Tutorials, onboarding docs, and CI jobs that used to include a separate MCP install now need only the dependency the repo already had.

That covers what 1.62 puts on the table. The Upgrade plan tab turns it into an order of operations: what to switch on first, and how to tell it paid off.

You do not adopt a release, you adopt features in the order they pay off. Playwright 1.62 hands a QA team five features worth real hours, and the order below is ours: flake control first because it pays on every single run, agent workflows last because they build on everything else.

Upgrade first, adopt in order

npm i -D @playwright/test@latest
npx playwright install

• No-drama upgrade. The 1.62 notes call out no breaking changes; every feature in this plan is additive, so the two commands above are the only mandatory part.
• What lands. The current 1.62 line (follow-up patches like 1.62.1 included), Chromium 151.0.7922.34, Firefox 153.0, WebKit 26.5, plus the bundled MCP server and CLI.
• Then adopt, one at a time. Do not flip every flag in one commit. Each feature below gets its own day and its own success signal, ordered by payoff per hour invested.

1. Isolated retries on the flakiest suite. Set retries with retryStrategy: 'isolated' so retries run at the end of the run, sequentially, in a single worker, then compare retry pass rates against your old inline retries.
2. One passkey login spec. Cover WebAuthn with context.credentials.create() plus context.credentials.install(), and persist it through the credentials storage state option so you log in once and reseed everywhere.
3. Quarantine list via Reporter.preprocess(). Move the flaky-test list into a reporter hook that calls testRun.skip(test), replacing grep-based skips scattered across CI scripts.
4. WebP on the heaviest visual suite. Point toHaveScreenshot() at .webp names and watch the repo size; comparisons stay lossless.
5. Agent workflows through MCP. Run npx playwright mcp, bundled with the runner since 1.62, and wire your agent skills to it.

The one-week rollout table

• One variable per day. Each move can be reverted independently, so nothing here is a migration.
• The signal is a number, not a feeling. Retry pass rate, a green spec, one file, repo size: if the number does not move, revert and move on.

Keep learning

• Review these tests with an agent. Wire an agent reviewer over the specs you just wrote with the QA code-review skill.
• Go deeper on the MCP server. The Playwright MCP masterclass covers the server end to end, from setup to agent-written tests.
• Score LLM output like a tester. The DeepEval masterclass turns "the agent seems right" into metrics you can gate on.
• Machine setup end to end. The batch setup guide takes a blank laptop to a running suite.

That is the whole plan: two commands, five adoptions, one signal per day, and anything that does not move a number gets reverted. For the rest of this series and every other guide, head back to the /ai hub.