Playwright 1.65: Bun Support, Failure-Only Reports and What to Check Before Upgrading

Playwright 1.65 at a Glance

From 1.64.1, you go two Chromium majors (156 to 158) and two Firefox majors (157 to 159). WebKit is at 27.2. On macOS 14, Playwright installs an older, pinned WebKit build (revision 2251 rather than 2388 as per browsers.json), so the WebKit results on macOS 14 and Linux can be different.

How Do You Run Playwright Tests Under Bun?

Run bunx --bun playwright test. The --bun flag is required. If you omit it, then bunx playwright test will run the test runner on Node.js as it did before. We checked process.versions inside a test: with the --bun flag, it reported Bun 1.4.4, and without it, it reported Node 22.

bun add -d @playwright/test@1.65.0
bunx playwright install --with-deps chromium   # installer, runs on Node.js
bunx --bun playwright test                     # test runner, runs on Bun

Under Bun, Bun transpiles your TypeScript test files itself. Playwright makes no use of Babel or its compilation cache.

The Playwright CI that runs the test-runner tests does so under Bun 1.4.3 on Linux. The release notes provide no minimum Bun version and say absolutely nothing about macOS or Windows, so pin Bun 1.4.3 or later and treat the other platforms as untested.

The notes also give no indication as to whether the playwright install should be run under Bun. Running it on Node as described above is the safe default.

What Breaks When Playwright Runs on Bun?

Watch mode, --tsconfig, tsconfig JSX options, custom ESM loaders, async stack frames and console capture in traces all work differently. The following table lists what the 1.65 notes document, plus two things we've observed:

What this means for CI:

• Step title dashboards have changed. We saw a TimeoutError: locator.click: ... under Node become a TimeoutError: click: ... under Bun. Keep the Bun and Node results in separate trend lines.
• Debug on Node. If you're debugging a flaky test, you'll be reaching for the UI mode re-runs, the async stack frames and the trace console output, and Bun gives you absolutely nothing in that respect.
• --only-changed PR gates run fewer tests under Bun. A change to a shared helper won't select the specs that import it.

How Do You Get a Playwright Report With Just the Failed Tests?

Use the new failures reporter for terminal output and onlyFailures: true for the HTML, JSON or JUnit file. There's no CLI flag for onlyFailures (a --reporter-only-failures flag was added during 1.65 dev and subsequently removed prior to release in #43805). Set it in your config or via an environment variable.

The failures reporter prints failures and successful retries as they happen, then a summary, and no progress output:

npx playwright test --reporter=failures

Options: omitTags (PLAYWRIGHT_FAILURES_OMIT_TAGS), plus PLAYWRIGHT_FORCE_TTY, FORCE_COLOR and NO_COLOR. Set quiet in the test config to suppress test stdout and stderr.

onlyFailures keeps the tests with unexpected results (including the ones with unexpected passes), the flaky tests and the tests that were interrupted. A flaky test is kept even if it passed on retry, along with all the attempts.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  reporter: process.env.CI
    ? [
        ['failures'],                                        // short CI log
        ['html', { onlyFailures: true, open: 'never' }],     // small artifact for humans
        ['json', { outputFile: 'results/full.json' }],       // full data for dashboards
      ]
    : [['list'], ['html']],
});

Env vars: PLAYWRIGHT_HTML_ONLY_FAILURES, PLAYWRIGHT_JSON_ONLY_FAILURES, PLAYWRIGHT_JUNIT_ONLY_FAILURES. We've confirmed both 1 and true work. Multiple reporters can be specified on the command line as a comma-separated list (e.g., --reporter=failures,blob).

Does onlyFailures Change Your Test Totals?

Yes, a filtered report doesn't just drop the passing tests; it drops them from the totals as well. We ran the same 24-test suite (21 passed, 2 failed, 1 flaky) both ways:

Anything that's going to work out a pass rate, a test count or 'tests added this week' from a filtered file is going to be complete and utter nonsense. The test management imports will think that 21 tests have disappeared. Have one unfiltered, machine-readable report (JSON or JUnit) for the dashboards and quality gates, and use onlyFailures for the HTML report that people actually look at.

How Do You Use onlyFailures With Sharded Blob Reports?

Don't put it on the blob reporter. Blob reporting has no onlyFailures option, and blobs should have the full run. Filter at merge time.

merge-reports --config will take a config which can be different from the one used to create the blobs:

// merge.config.ts
export default {
  testDir: 'tests',
  reporter: [
    ['html', { onlyFailures: true, open: 'never' }],
    ['junit', { outputFile: 'results/junit.xml' }], // unfiltered, for your test-management import
  ],
};

npx playwright merge-reports --config=merge.config.ts ./all-blob-reports

Keep the blobs as a short retention artifact (1-3 days) and the failure-only HTML report for anything longer.

Watch out for this 1.65 change: the blob reporter is deleting the contents of its output directory again before it writes. We ran two invocations with different file filters into one blob-report/ folder, and the second one wiped out the first. If one job is running Playwright more than once, then each run should have its own outputDir or PLAYWRIGHT_BLOB_OUTPUT_FILE.

How much storage does it save? Playwright doesn't publish a figure for that, and we certainly won't. The HTML report has a fixed app shell (around 0.5MB in our run) regardless of whether you've filtered it or not.

The savings are in the traces, videos and screenshots from the tests themselves. onlyFailures will only filter the report, and test-results/ will still contain all of your traces, videos and screenshots as per your configuration.

To get the savings, you need to pair it with trace: 'retain-on-failure' or 'on-first-retry'. Measure it on your own suite:

PLAYWRIGHT_HTML_OPEN=never npx playwright test --reporter=html; du -sh playwright-report
PLAYWRIGHT_HTML_OPEN=never PLAYWRIGHT_HTML_ONLY_FAILURES=1 npx playwright test --reporter=html; du -sh playwright-report

Why Do Page Objects Throw 'Cannot Read Properties of Undefined' in Playwright 1.65?

Playwright 1.65 now compiles TypeScript class fields in accordance with useDefineForClassFields, just like tsc does. That setting is on for ES2022+ targets and when the target is unset (which covers projects with no tsconfig.json at all; we've tested that). Field initializers now run prior to the constructor assigning the parameter properties:

class LoginPage {
  // 1.65: TypeError: Cannot read properties of undefined (reading 'getByRole')
  readonly submit = this.page.getByRole('button', { name: 'Submit' });
  constructor(private readonly page: Page) {}
}

Find every case with the compiler rather than grep. With target ES2022 or unset, tsc reports these lines precisely as TS2729: Property 'page' is used before its initialization:

npx tsc --noEmit -p . 2>&1 | grep TS2729

If you've got no tsconfig, then just run npx tsc --noEmit --target es2022 --skipLibCheck <files> or add a minimal tsconfig. If you're doing a grep, you need to cover the modifiers and the type annotations. A pattern that only matches readonly x = this.page will completely miss private readonly x: Locator = this.page...

rg -n --type ts '^\s*(?:(?:public|private|protected|readonly|static|override)\s+)*#?\w+\??!?\s*(?::[^=]+)?=\s*this\.'

Fix: move the initializers into the constructor, or set "useDefineForClassFields": false in tsconfig.json.

If you're using decorated classes with static fields, then false currently breaks loading. See #43936 under known bugs.

Which Other Playwright 1.65 Breaking Changes Got Picked Up by CI?

Nine more, ordered by how often we expect them in a typical suite:

• Actions wait for elements to be non-inert. click, check, tap, fill, clear, and selectOption all time out on an element that has the inert attribute or is inside one. The call log will simply state that the element is inert, so grep the logs for that string. The usual culprit is a test that has clicked behind an open modal or drawer.
• An empty sharded run will fail with "No tests found". If no tests match across all the shards, then the run will fail. A single empty shard will still pass if the other shards have tests. If you're deliberately running with an empty --grep, then you should add --pass-with-no-tests.
• Aria names skip unrendered text. Text that isn't assigned to a slot, or which is directly within a closed <details>, no longer counts. This will affect getByRole({ name }), ariaSnapshot() and toMatchAriaSnapshot().
• Cookie matching is per RFC 6265. browserContext.cookies(url) and apiRequestContext.cookies(url) no longer return host-only cookies for subdomains or Path=/api cookies for /apiv2. A Path=/foo/ cookie no longer matches /foo. Nameless cookies are now sent as Cookie: x rather than Cookie: =x.
• APIRequestContext params append. String and URLSearchParams values are appended to the URL's existing query string rather than replacing it.
• Proxy credentials only deal with proxy challenges. This is a security fix, as the launch({ proxy }) username and password were being sent to any site that asked for authentication. For site logins, use httpCredentials on the context.
• .css, .less and .scss imports load as empty modules rather than being stripped; the file must exist.
• The blob reporter clears out its output directory (as per above).
• CommonJS test locations point to the callee start (e.g. a.spec.ts:3:7 rather than 3:11), which is in keeping with ESM. That's going to matter if you're using file:line:col as a key in your history.

One thing is missing from the release notes. APIRequestContext now JSON-encodes string data for content types such as application/json;charset=UTF-8 and Application/JSON. Previously, only the exact string application/json was encoded. See #43937.

Will Playwright 1.65 Change Your Screenshot Baselines?

Expect some drift in all three engines if you use toHaveScreenshot(). The first public upgrade PRs show it:

• beaket/ui 1.64.1 to 1.65.0: visual suite failed 37 of 288 screenshots at mobile, tablet and desktop widths (issue #1234). The author thinks it's down to Chromium 158 text rendering but hasn't verified this yet.
• vaadin/web-components: the 1.65.0 upgrade PR required a follow-up commit, "fix Firefox and WebKit failures after Playwright 1.65 update" before it could be merged (PR #13362).
• primer/react refreshed 162 baselines, but that PR goes from 1.60 to 1.65 (Chromium 148 to 158) and is still open, so it overstates the 1.64 to 1.65 upgrade (PR #8690).

Regenerate the baselines within the Docker image for the same version (mcr.microsoft.com/playwright:v1.65.0-noble) in a separate commit and have a human have a look at the diff images. The baselines are regenerated in a separate commit so that you can revert the baselines without having to revert the code fixes.

There's one plus for Firefox users. 1.64 Firefox couldn't move focus from an iframe back to the parent (issue #43280, labeled v1.65 and closed 16th Oct). Some teams were actually still on 1.63 for that very reason (mittwald/flow#3607).

Which Version of Node.js and Which Docker Image Does Playwright 1.65 Require?

Node.js 22, 24, or 26 (latest patch of each). Playwright no longer tests on Node.js 20. The "engines" field in the 1.65.0 package still says "node": ">=20", so npm will install on Node 20 without a warning. You'll need to enforce this yourself.

// package.json
{ "engines": { "node": ">=22" } }

# .npmrc
engine-strict=true

Docker images now come with Node.js 26 (was 24). If you have any native modules in your app that were built against Node 24, you'll need to re-build those. 1.65.0 tags:

The images contain Node.js, not Bun. The image tag must match your @playwright/test version; otherwise, Playwright won't be able to find its browsers. Supported hosts: Windows 11+, Server 2019+, WSL, macOS 14+, Debian 12/13, Ubuntu 22.04/24.04/26.04.

Known Playwright 1.65.0 Bugs (as of November 6, 2026)

No 1.65.1 has shipped yet. Three reports from the first day:

Playwright 1.65 Upgrade Checklist

Paste this into the upgrade PR:

• Node.js: CI and Dockerfiles on 22, 24 or 26; engines raised to >=22.
• One Playwright version: npm ls @playwright/test playwright playwright-core shows only 1.65.0 (monorepos will invariably have a spare copy somewhere).
• Browsers: npx playwright install --list gives us chromium-1254, firefox-1572 and webkit-2388 (webkit-2251 on macOS 14).
• Browser cache: if you do cache ~/.cache/ms-playwright (the docs actually advise against this) then key it on the Playwright version.
• Docker tags: rg -n "playwright:v1\.[0-9]+\.[0-9]+" finds no old tag. Primer's first pass missed five containers.
• Class fields: tsc --noEmit has no TS2729 errors, or useDefineForClassFields: false is set on purpose.
• Decorators: no decorated classes with static fields plus useDefineForClassFields: false (#43936)
• Inert: no failures containing element is inert, or each one fixed in the test.
• Baselines: regenerated in the v1.65.0 image, separate commit, diffs reviewed.
• Aria snapshots: toMatchAriaSnapshot() specs re-run and reviewed.
• Reports: dashboards and quality gates read the unfiltered report (not the onlyFailures one).
• Blob reporter: one output directory or file name per invocation.
• Sharding: intentionally empty runs pass --pass-with-no-tests.
• API tests: string bodies with application/json;charset=... (#43937), params on URLs that already have a query, cookie assertions by URL.
• Auth: no site login via proxy credentials.
• Remote browsers: your grid or connect() server is running Playwright 1.65.x. browserType.connect() requires the client and server to match on major.minor.

How to Upgrade a CI Suite to Playwright 1.65, Step by Step

Approx. 15 minutes hands-on, plus two runs of your suite.

git switch -c chore/playwright-1.65
npm install -D --save-exact @playwright/test@1.65.0
npx playwright install --with-deps
npx playwright --version   # Version 1.65.0

npx tsc --noEmit 2>&1 | grep TS2729            # class-field breakage
npx playwright test --list > /dev/null         # load errors, e.g. #43936
rg -n "playwright:v1\.[0-9]+\.[0-9]+" .        # Docker tags to bump

docker run --rm --ipc=host -v "$PWD":/work -v /work/node_modules -w /work \
  mcr.microsoft.com/playwright:v1.65.0-noble \
  /bin/bash -c "npm ci && npx playwright test --reporter=failures"

docker run --rm --ipc=host -v "$PWD":/work -v /work/node_modules -w /work \
  mcr.microsoft.com/playwright:v1.65.0-noble \
  /bin/bash -c "npm ci && npx playwright test --update-snapshots"
git add -A -- '*-snapshots/*' && git commit -m "test: refresh baselines for Playwright 1.65"

How to Roll Back From Playwright 1.65 to 1.64.1

Use four commits: (a) version bump and lockfile, (b) code fixes, (c) baselines, (d) 1.65-only config. To roll back, revert (a), (c) and (d). Keep (b) as it contains the constructor initialization, httpCredentials, --pass-with-no-tests and Buffer bodies, all of which work on 1.64.

Commit (d) matters because 1.65 config fails on 1.64 in different ways. We tested each one on 1.64.1:

Then:

npm install -D --save-exact @playwright/test@1.64.1
npx playwright install --with-deps

Switch the Docker tags back to v1.64.1-noble and revert the Bun CI job back to npx playwright test, as Bun support doesn't start until 1.65.

GitHub Actions Workflow: Playwright 1.65 Under Bun With Sharding

Four shards under Bun, blob reports, then one merged failure-only HTML report and an unfiltered JUnit file.

Action versions are in line with the current Playwright CI docs.

# .github/workflows/playwright-bun.yml
name: Playwright 1.65 (Bun)
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    strategy:
      fail-fast: false
      matrix:
        shardIndex: [1, 2, 3, 4]
        shardTotal: [4]
    steps:
      - uses: actions/checkout@v6
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: 1.4.3              # the version Playwright's CI uses
      - run: bun install --frozen-lockfile
      - run: bunx playwright install --with-deps   # installer runs on the runner's Node.js
      - name: Run tests under Bun
        run: bunx --bun playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }} --reporter=failures,blob
      - uses: actions/upload-artifact@v5
        if: ${{ !cancelled() }}
        with:
          name: blob-report-${{ matrix.shardIndex }}
          path: blob-report
          retention-days: 2

  report:
    if: ${{ !cancelled() }}
    needs: [test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: 1.4.3
      - run: bun install --frozen-lockfile
      - uses: actions/download-artifact@v5
        with:
          path: all-blob-reports
          pattern: blob-report-*
          merge-multiple: true
      - name: Merge into failure-only HTML + full JUnit
        run: bunx playwright merge-reports --config=merge.config.ts ./all-blob-reports
      - uses: actions/upload-artifact@v5
        with:
          name: playwright-report-${{ github.run_attempt }}
          path: |
            playwright-report
            results/junit.xml
          retention-days: 14

merge.config.ts is the file from the sharding section. To stay on Node.js, replace setup-bun with actions/setup-node@v6 (node-version: 24), replace bun install --frozen-lockfile with npm ci, and replace bunx --bun with npx.

Checking Playwright 1.65 on Real Browsers Before You Merge

The container run does a check of the Playwright bundled browser builds on one Linux image. Your users will be running their branded Chrome and Edge, Safari on macOS and iOS, and Chrome on Android.

1.65 was tested against Chrome 157 and Edge 156 stable (not the same builds as the bundled Chromium 158). WebKit on macOS 14 is a different build from WebKit on Linux. A screenshot or focus difference can pass in your container and still fail for a customer.

TestMu AI runs an existing Playwright suite on their cloud across 3,000+ browser and OS combinations as well as real Android and iOS devices. The browser and OS versions are selected on a per-run basis. The Playwright docs will cover the connect() setup.

For sharded suites, HyperExecute will take a single YAML file and shard the tests out across the machines to run the browser x OS matrix. Each test will have its own video, screenshots, and console and network logs, so you're not at all disadvantaged in terms of the evidence from the tests that passed if you're just getting a failure-only HTML report.

If you'd rather just run a flow from the terminal rather than write out a spec first, then the Kane CLI will take a plain English description and give you a pass/fail verdict complete with the steps, screenshots and logs. Recorded flows can be exported as Playwright code.

Should You Upgrade to Playwright 1.65.0 Right Now?

Yes, if tsc shows no TS2729 errors and you can refresh baselines in a reviewed commit. The bulk of the breaking changes are one-liners, which also work on 1.64, and Firefox iframe focus is back. If you're using decorated page objects with useDefineForClassFields: false, then you should wait for 1.65.1 (#43936).

Bun is opt-in, so there's no reason to wait or to rush. Just try it in a separate CI job and keep Node.js as your reference run.

Conclusion

Start the Playwright 1.65 upgrade on a branch with tsc --noEmit, which finds the class-field breakage before a browser runs. Then run your suite in the v1.65.0 image, sort each failure into a bucket, and put refreshed baselines in their own commit so you can roll back cleanly.

Testing from the terminal? Kane CLI by TestMu AI lets SDETs and developers plan, write, run and debug tests from the command line.

To run your first test, start free, or

book a demo

for a full walkthrough of the product.