Playwright Triage

Playwright Issue Triage

Triage a GitHub issue by working out what it actually is, then doing the right thing for that kind.

The goal is a clear, verified status, not a fix.

First, classify the issue

Judge by the content, not the label — a "[Feature]" is often really a bug (something already

*should* work), and a "[Bug]" is sometimes expected behaviour. Work out what it actually is:

• Bug — reproduce it. The bulk of this skill.
• Feature request — nothing to reproduce. Check it doesn't already exist (search docs/API,

maybe under another name), verify any source the reporter cites by reading it, and surface the

real design question. If it's small and well-scoped (like "fail loudly instead of

silently"), the ideal takeaway is an acceptance test: one self-contained spec asserting

*current* behaviour (passes today) with the *desired* behaviour alongside as a fixme/commented

assertion.

• Upstream / environment — a genuinely external owner (the Node project, a browser engine, a

website's own server/cert config), not Playwright. Find the real owner, don't brute-force a repro,

verify any cited upstream issue and point at the real fix path. Note: the Playwright family —

@playwright/mcp (source lives here under packages/playwright-core/src/tools/mcp/),

playwright-vscode, -python, -java, -dotnet — is not "upstream"; it's us. Never tell a

reporter to refile within the project (see below).

• Question / usage — answer it or point at the docs.

The rest of this skill is the bug path.

Reproducing a bug

You're not in a hurry, so be exhaustive before giving up.

If the user has provided a minimal repro, try it first. If it does not repro for you, play around with things they might have forgotten to mention:

all three browsers, headed/headless, a few recent versions, and variations of the snippet or trigger.

Report "cannot reproduce" only after you've genuinely explored — and say what you tried.

If you have a hunch for what information would help, ask for it.

Run across browsers, and watch for divergence — a bug that only reproduces in webkit, or

everywhere *except* firefox, is a strong signal worth leading with. Plenty of bugs are

browser-agnostic, though, and those are just as real: reproducing on every browser is a good

result to report, not a non-finding.

• Read the whole thread, comments included — the missing repro or narrowed trigger is often there.
• Pull the inputs: version, browser(s), OS, repro repo/snippet, Expected-vs-Actual (your oracle).

If something's missing, guess and try anyway; note assumptions in the report.

• Reproduce on tip-of-tree first, in ~/tmp/issue-<number>/: clone the linked repo, or

scaffold npm install @playwright/test@next with a single-project config (see

bisect-published-versions.md). Use

PLAYWRIGHT_HTML_OPEN=never. If it reproduces on ToT, it's a live bug — record the exact

version/sha you tested, and if it looks like a regression, bisect it (see the guide).

• If ToT doesn't reproduce it, try the version the user reported. If it reproduces there but

not on ToT, it's already fixed — find the version/PR that fixed it (a cherry-pick may still

be worth it). If neither reproduces, it's incomplete or env-specific — say what you couldn't

match. (A version ending in -next, e.g. 1.62.0-next, is not an npm version — it means

tip-of-tree, which is the @next build you already tried.)

To step through a test interactively, use the playwright-cli skill.

Reports sometimes target another part of the Playwright project — @playwright/mcp (its source is

in this repo), playwright-vscode, playwright-python, playwright-java, playwright-dotnet.

These are all us, so triage them like anything else: check out that repo and reproduce there in

its own language/toolchain when needed. Never tell the reporter the issue belongs in a different

Playwright repo or should be refiled there — that's an internal routing detail, not the reporter's

problem.

Condense the repro into a self-contained test

Big or app-specific repros are much more useful boiled down to a single self-contained spec,

written the way our tests are: one test(...) using the page and server fixtures, tagged

with the issue link. Crucially:

• No test.beforeAll / afterAll, no http.createServer, no manual setup/teardown. The

fixtures already give you a page and a web server. Use server.setRoute(...),

server.setRedirect(...), server.PREFIX, server.EMPTY_PAGE instead of standing up your own.

• Drive the page with page.setContent(...) or page.goto(server.PREFIX + '/...').
• Keep only what's needed to trigger the bug, and end on the assertion that fails.

Drop it into the repo (tests/page/) and run it with npm run ctest.

Mirror real self-contained tests, e.g.:

• tests/page/page-network-request.spec.ts — should return event source: server.setRoute SSE endpoint, no lifecycle hooks
• tests/page/selectors-css.spec.ts — should use light DOM structure for child combinator with slotted content: page.setContent with inline shadow DOM (#37768)
• tests/page/workers.spec.ts — should report worker script as network request after redirect: server fixture with routes/redirects + a browser-gap fixme (#35678)

Report

Give a status that fits the issue type — for a bug: reproduced / fixed-on-latest /

cannot-reproduce / not-a-bug; for a feature request or upstream/env issue: a short verdict

(already-possible, valid request, upstream — owned by X) — plus the evidence. For bugs, include

the condensed repro and be exhaustive about what you ran — the full matrix of browsers,

versions, and variations you tried, not just the one that worked — so the reader can trust the

verdict and skip re-checking. Call out any browser-specific divergence. Write it in the

Playwright bot voice (.github/workflows/bot-voice.md, relative to the repo root) — maintainer voice, not AI-speak.

Watch out

• Only run code you trust — skim a linked repo/snippet first; bail and report that in the issue

comment if it has postinstall scripts, obfuscated code, or random small libraries.

• Triage ends at a reproduction and a status; don't jump to a fix.