testaro 78.0.8 → 78.6.0

package/validation/act/chromium-issue-draft.md

@@ -0,0 +1,66 @@
+# Chromium bug report — Target.closeTarget acks success without closing during navigation commit
+
+**NOT FILED as a new issue — already tracked upstream.** Pre-filing search (2026-08-22) found
+<https://issues.chromium.org/issues/536385539> (filed 2026-07-19 by a Google engineer, P2/S2,
+pending code change 8251379): `Target.closeTarget` is lost when a navigation commit swaps the
+main RenderFrameHost right after `ClosePage` — the pending `ClosePage` callback dies with the
+old RFH and is never re-issued. Same defect; their trigger was back-to-back failing navigations,
+ours (meta-refresh 0) is an additional ordinary-page trigger of the same race.
+
+**Actions taken instead:** corroborating comment posted as comment #2 on 536385539 (meta-refresh
+trigger, raw-CDP hit rates, workaround matrix, link to
+<https://github.com/microsoft/playwright/issues/42366>); issue upvoted; cross-link comment added
+on the Playwright issue. Repro retained here: `repro-cdp-raw.js`.
+
+The draft below is preserved for reference (its evidence went into the comment).
+
+---
+
+**Title:** Target.closeTarget returns success:true without closing the target when the close
+races a client-side (meta refresh) navigation commit; no Target.targetDestroyed is ever emitted
+
+## Environment
+
+- Chromium 151.0.7922.34, `--headless=new`, Linux
+- Raw CDP over WebSocket (no client library — reproduces identically through Playwright 1.62.1,
+  where it strands `page.close()` forever)
+- Not reproducible in Firefox or WebKit equivalents
+
+## Steps
+
+1. Create a target and navigate it to a page carrying
+   `<meta http-equiv="refresh" content="0; URL='/target.html'">` (immediate client-side
+   redirect).
+2. Leave a `Runtime.evaluate` (`awaitPromise: true`) in flight for the refresh navigation to
+   destroy.
+3. ~45–60 ms after the navigate (during the refresh navigation's commit window), send
+   `Target.closeTarget {targetId}` on the browser session.
+
+Reproduction rate ~3/10 rounds with the attached script (a timing race; the script sweeps the
+window).
+
+## Expected
+
+Either the target closes — `Target.targetDestroyed` fires and the target disappears from
+`Target.getTargets` — or `closeTarget` reports `success: false`/an error.
+
+## Actual
+
+`closeTarget` returns `{"result":{"success":true}}`, but:
+
+- no `Target.targetDestroyed` is ever emitted for the target;
+- the target remains listed in `Target.getTargets`;
+- the target proceeds to fully load the redirect destination (frameNavigated,
+  DOMContentLoaded, load, paint lifecycle events all arrive *after* the successful-looking
+  close acknowledgment).
+
+A second `Target.closeTarget` for the same target afterwards does close it, as does closing its
+browser context — the target is not stuck, the close was simply dropped.
+
+## Impact
+
+Any CDP client that treats `success: true` as "the target will be destroyed" waits forever.
+Playwright's `page.close()` does exactly this: its promise resolves on target destruction, so
+automation against pages using meta-refresh (common in the wild; the W3C ACT-Rules bc659a
+"passed" fixtures are examples) hangs nondeterministically with no error. Observed at ~70–80%
+per attempt via Playwright's timing on real fixture pages.

package/validation/act/fp-triage-2026-08-22.md

@@ -0,0 +1,86 @@
+# Pour FP triage — 2026-08-22 capture (440-testcase sample, asserted band)
+
+Manual read of every pour false-positive fixture from `results/merged-2026-08-22.jsonl`.
+Verdicts: **real** (pour asserts a failure ACT deems passed/inapplicable — upstream candidate) or
+**artifact** (correct finding counted against the wrong ACT rule by the criterion-level scoring
+policy — not a pour defect).
+
+## Real — upstream filing candidates
+
+1. **Contrast asserted on ACT-exempt text** (3 FPs, `afw4f7`/`09o5cg`). Symbol-only text
+   (`09o5cg` Passed Ex 6: a paragraph of `----====++++…` at 3.66:1) and letter-as-icon glyphs
+   (`afw4f7` Passed Ex 7 / `09o5cg` Passed Ex 6: `<button aria-label="Close">X</button>`) are
+   expected *passed* by the ACT contrast rules; pour's `color-contrast` /
+   `color-contrast-enhanced` assert failures. Axe returns no finding on all three (TN). Given
+   pour's "report what it cannot prove" ethos, asserting on ACT-consensus-exempt text is worth an
+   upstream issue.
+2. **`button-name` on `<button role="none" disabled>`** (1 FP, `97a4e1` Inapplicable Ex 5). With
+   the element disabled (not focusable), `role="none"` holds and the element is out of scope for
+   the button-name rule; pour flags it.
+3. **`link-name` misses descendant `aria-labelledby`** (1 FP, `c487ae` Passed Ex 8):
+   `<a href><img aria-labelledby="id1"></a>` — the link's name-from-content includes the image's
+   aria-labelledby name, so the link is correctly named; pour flags it empty. Accessible-name
+   computation gap.
+4. **Language rules skip ACT applicability conditions** (4 FPs, `de46e4`/`off6ek`/`ucwvc8`).
+   `valid-lang-parts` flags invalid `lang` values on elements whose text is overridden by a
+   descendant `lang` or entirely `display:none` (ACT: passed/inapplicable — the SC concerns text
+   that *uses* the language); `html-lang` flags a completely empty `<html></html>` page (ACT:
+   inapplicable without text). Defensible strictness, but a divergence from ACT consensus worth
+   raising upstream.
+
+## Artifact — scoring policy, not pour
+
+- **`c487ae` Inapplicable Ex 4** (`<a aria-hidden="true" href>…</a>`): pour's `aria-hidden-focus`
+  finding is a *correct* 4.1.2 issue (focusable content hidden from AT); it counts as an FP only
+  because the fixture tests a different ACT rule on the same criterion. This is the documented
+  generosity of criterion-level matching; an exact engine-rule → ACT-rule map would reclassify it.
+
+## Tally
+
+Of 15 criterion-level FPs in the sample, ~9 fixtures inspected covering all hotspots: 9 real
+across 4 defect classes, 1 artifact. The 4 classes are small, well-defined applicability/name-
+computation gaps — exactly the kind of finding the candidacy pipeline is meant to hand upstream
+(engine-candidacy-pipeline.md, Stage 5 / benchmarks §6 stewardship).
+
+## Recheck 2026-09-01 (pour 1.37.0, surea11y 1.7.0)
+
+Re-ran every fixture of the eight ACT rules above with the current bundles
+(`--engines pour,surea11y --rules afw4f7,09o5cg,97a4e1,c487ae,de46e4,off6ek,ucwvc8,4b1c6c`).
+
+- Pour classes 1–3 persist unchanged in 1.37.0 (contrast on `afw4f7`/`09o5cg` Passed Example 7,
+  `button-name` on `97a4e1` Inapplicable Example 5, `link-name` on `c487ae` Passed Example 8).
+  Contrast also asserts on `09o5cg` Inapplicable Examples 6 and 7 — label text of a disabled
+  control, which ACT's "disabled label" applicability exemption excludes — a third sub-case of
+  class 1. Class 4 narrows to `valid-lang-parts` (`de46e4` Passed Example 4, Inapplicable 3–5,
+  `off6ek` Inapplicable 5): the `html-lang` hits on empty documents (`ucwvc8` Inapplicable 2–3,
+  `97a4e1` Passed 6, `c487ae` Passed 9) are correct under ACT `b5c3f8`, whose applicability has
+  no content condition, and count as FPs only through criterion-level scoring. Same for
+  surea11y's `html-lang-attr-present` on those fixtures.
+- **surea11y `4b1c6c` (11 FP)** is `iframe-title-unique`, not the 1.7.0 rule
+  `identical-iframes-same-purpose` (which already reports differing resources as `cantTell`):
+  it fails any two frames sharing a title attribute, including Passed Examples 1, 4–9 where the
+  frames embed the same or equivalent resource, and Inapplicable Example 5.
+- Upstream filings prepared from this recheck: pour — presentational-role conflict ignoring
+  `disabled`, name-from-content ignoring descendant `aria-labelledby`, contrast on
+  non-human-language text / icon glyphs / disabled labels, `valid-lang-parts` applicability;
+  surea11y — `iframe-title-unique` vs ACT 4b1c6c.
+
+### Filed upstream 2026-09-01 (pour-engine)
+
+| Class | Issue | Pull request |
+| --- | --- | --- |
+| button-name on `<button role="none" disabled>` (presentational-role conflict ignores `:disabled`) | [#3](https://github.com/pourdev/pour-engine/issues/3) | [#7](https://github.com/pourdev/pour-engine/pull/7) |
+| link-name: name from content ignores a descendant's `aria-labelledby` | [#4](https://github.com/pourdev/pour-engine/issues/4) | [#8](https://github.com/pourdev/pour-engine/pull/8) |
+| contrast on symbol-only text, single-letter icons, labels of disabled widgets | [#5](https://github.com/pourdev/pour-engine/issues/5) | [#9](https://github.com/pourdev/pour-engine/pull/9) |
+| valid-lang-parts on `lang` attributes that govern no text | [#6](https://github.com/pourdev/pour-engine/issues/6) | [#10](https://github.com/pourdev/pour-engine/pull/10) |
+
+### Filed upstream 2026-09-01 (surea11y core)
+
+| Class | Issue | Pull request |
+| --- | --- | --- |
+| `iframe-title-unique` fails frames sharing a title that embed the same resource (ACT 4b1c6c) | [#16](https://github.com/SureA11y/core/issues/16) | [#17](https://github.com/SureA11y/core/pull/17) |
+
+The maintainers document the strict behaviour as deliberate (`docs/ACT_RULE_MAPPING.md`), so the
+issue asks them to choose between aligning the rule with 4b1c6c (the PR) and deprecating it in
+favour of `identical-iframes-same-purpose`. Fixture branches live on the forks
+`wittjeff/pour-engine` and `wittjeff/core`.

package/validation/act/isolation-notes.md

@@ -0,0 +1,159 @@
+# Long-lived-browser injection failure — evidence log (2026-08-22)
+
+Motivation beyond this harness: production testaro launches a fresh browser per test act because
+of recurring spurious test-isolation bugs, at a large throughput cost. Anything learned here about
+what long-lived-browser state actually breaks — and what level of recycling (context vs browser)
+resets it — bears on whether that cost can be reduced.
+
+## The incident
+
+Full ACT capture (1,213 testcases × pour + axe, one Chromium browser + one context for the whole
+run, fresh page per testcase × engine, pages closed after use). From testcase 274 — exactly the
+first fixture of rule `7d6734`, immediately after the last `c487ae` fixture — **every** pour row
+for the remainder of the run (940 rows) failed the same way: script element inserted, no
+exception, `pourEngine` global never defined. Axe, whose adapter executes via `page.evaluate`
+instead of a `<script>` tag, kept detecting instances to the final row. No recovery for ~940
+consecutive pages over ~13 minutes.
+
+## Experiments
+
+| # | Setup | Result |
+| --- | --- | --- |
+| 1 | Fresh process, the boundary fixtures (`7d6734`, `afw4f7`) | All pass — fixtures innocent in isolation |
+| 2 | 700 cycles, local benign fixtures, one browser, axe-style page interleaved (data-xpath stamping + axe evaluate), no recycling | 0 failures, flat RSS — page count + interleave alone insufficient |
+| 3 | Full-feed pour re-capture, browser recycled every 100 testcases, no axe interleave | Clean through the entire former cliff region (34/34 on `7d6734`/`307n5z`/`a25f45`) |
+| 4 | Cliff-neighborhood replay (`c487ae`→`a25f45`, 69 testcases), pour + axe interleaved, **no recycling**, fresh process | 69/69 clean — the fixture region + interleave is not a deterministic trigger |
+| 5 | Full-feed pour-only recapture, hardened harness, solo machine, recycling every 100 | **Cliff recurred**: 41 consecutive rows dead starting mid-`1a02b0` (video-transcript fixtures) — in a browser only ~36 pages old. Rules out cumulative-pages-per-browser; the concurrent-load theory weakens too (run was solo). |
+| 6 | Meta-refresh(0) fixtures, local repro (`repro-metarefresh.js`): goto → evaluate (interrupted by the refresh navigation) → `page.close()` | **`page.close()` hangs indefinitely** — never resolves, never rejects — on ~half the rounds, on both a single-redirect page and an a→b→a redirect loop. Playwright 1.62.1, Chromium headless. The context stays usable for *new* pages afterward. Independently, both full captures wedged at exactly the first `bc659a` ("Meta element has no refresh delay") fixture — its passed examples are `content="0; URL=…"` immediate redirects — frozen >35 min in an untimeouted `await page.close()`. |
+| 7 | Replay of the recurrence region (`1a02b0`,`2ee8b8`,`59br37`, 61 testcases), no recycling, fresh process | 61/61 clean — the video region is not a deterministic trigger either. |
+| 8 | Wedged-browser aftermath (from the bc659a incident): `newPage` on the wedged browser | Throws `Protocol error (Target.createTarget): Not supported`, then `Target page, context or browser has been closed` once the process dies — a recognizable signature usable as a replace trigger. A deadline-only trigger let 73 rows (pour) / 886 rows (qualWeb) fail before the next scheduled recycle. |
+
+## Conclusion: probabilistic wedge events, answered by canary-triggered recycling
+
+The injection cliff is **nondeterministic**: it recurred at a different position in a nearly-new
+browser on a quiet machine, and every regional replay of a cliff neighborhood comes back clean.
+Best model: races between fixture-initiated behavior (media load, client-side navigation) and
+harness operations occasionally wedge browser-wide `<script>`-element execution — same family as
+the reproducible close() hang, at roughly 1–2 events per ~1,200 real-page cycles. Chasing a
+deterministic trigger further has diminishing value; the effective countermeasures, all now in
+`capture.js`, are:
+
+1. **Deadline-race every browser-touching await** (nothing can hang the loop);
+2. **Canary assertions** (expected tool global present on text/html pages);
+3. **Replace the browser on any wedge signature**: tripped deadline, `Protocol error
+   (Target.createTarget)`, "has been closed", or a failed canary.
+
+## Upstream status (2026-08-22)
+
+- Playwright: filed as <https://github.com/microsoft/playwright/issues/42366> (likely duplicate
+  of #42068, which the team milestoned v1.63); **fix PR submitted:**
+  <https://github.com/microsoft/playwright/pull/42367> (bounded re-issue of `Target.closeTarget`
+  in `CRBrowser._closePage` + stale-fixme removal; their close-related suites pass 41/41).
+  Note: Playwright's rolled Chromium 152.0.7977.54 narrows the race window sharply through
+  Playwright's call timing (their reload-trigger test passes 6/6 unpatched), but raw CDP still
+  reproduces the contract violation on 152 (~2/10) — so channel builds (Chrome/Edge stable,
+  151-class, 70–80% hit rate) remain the population the guard protects.
+- testaro: `browserClose` hardened with a 10 s settle-deadline per close (try/catch cannot catch
+  non-settlement) — PR <https://github.com/YRA-Tech/testaro/pull/92>. (Discovered en route:
+  jrpool/testaro now redirects to YRA-Tech/testaro — the repo was transferred, so #92 IS the
+  upstream PR.) The same patch is applied to the working tree used by the harness.
+- Chromium: already tracked as <https://issues.chromium.org/issues/536385539> (filed 2026-07-19
+  by a Google engineer; P2/S2; **pending code change 8251379**). Their C++ root cause matches our
+  protocol-level one exactly: `WebContentsImpl::ClosePage` arms the close on the current main
+  RenderFrameHost; a racing navigation commit swaps the RFH; the pending `ClosePage` callback
+  dies with the old RFH and is never re-issued. Our meta-refresh(0) trigger, hit rates, and
+  workaround matrix posted there as comment #2; both issues cross-linked. Practical upshot for
+  testaro: a fix is in flight upstream, but the deadline+canary+context-recycle defenses remain
+  necessary until it ships in a released Chromium — and for the injection cliff, which has no
+  upstream issue yet.
+
+## Discovery #2 — root-caused (2026-08-22 evening)
+
+A `DEBUG=pw:protocol` trace of a hanging round shows the full mechanism: Playwright sends
+`Target.closeTarget`, Chromium replies `{"result":{"success":true}}`, but the target — mid-commit
+in the meta-refresh navigation — never closes; the same session then emits the redirect
+destination's entire load lifecycle after the "successful" close, `Target.targetDestroyed` never
+fires, and `page.close()` waits for it forever. Chromium acknowledges a close it does not
+perform; Playwright trusts the acknowledgment with no timeout.
+
+Matrix (10 rounds/cell): **Chromium-only** (Firefox 153 and WebKit: 0/10 everywhere), and
+**default `close()` only** — `close({runBeforeUnload: true})` 0/10, `context.close()` 0/10.
+After a hang, `context.close()` still settles and destroys the page (**8/8 recoveries**).
+
+The recovery result upgrades the production recommendation: for this wedge class,
+**context-level teardown is a sufficient and reliable recovery** — no browser relaunch needed
+(~10 ms vs ~300 ms). A pooled-browser testaro could run context-per-act with deadline-raced
+closes, escalating to browser replacement only if the context teardown itself trips its
+deadline. (The injection cliff's recovery level remains untested — it is not reproducible on
+demand — so the escalation path should stay.)
+
+## Discovery #2 (original observation): page.close() can hang forever after a meta-refresh navigation
+
+This is a second, *reproducible-at-will* failure mode, distinct from the injection cliff but in
+the same family (navigation racing teardown corrupts page state):
+
+- Signature: `close()` neither resolves nor rejects, so `await page.close().catch(...)` blocks
+  forever — `.catch` guards rejection, not non-settlement. A loop with no deadline around close
+  freezes permanently, silently.
+- Nondeterministic (~50% of rounds locally): it is a race with the refresh-triggered navigation,
+  which also explains why one run passes a fixture another run wedges on.
+- No matching upstream issue found (2026-08-22 search); nearest family member is
+  [playwright#33806](https://github.com/microsoft/playwright/issues/33806) (hangs waiting for
+  pending navigations). **Fileable** with `repro-metarefresh.js` (~40 lines, local pages, no
+  external deps beyond playwright + any large script to inject — the script is incidental).
+- Harness guard shipped in `capture.js`: every browser-touching await is raced against a
+  deadline (`withDeadline`), a tripped deadline presumes a wedged browser and replaces it
+  (`replaceBrowser`, itself deadline-guarded), and captures resume by skipping rows already in
+  the out file. Verified against the live `bc659a` fixtures: one real close-hang tripped the 5 s
+  deadline, the browser was replaced, and all 15 fixtures completed.
+
+### Production translation (testaro)
+
+Pages that navigate during scanning (meta refresh is common on real sites) can hang `close()`
+forever. In a browser-per-act world the leaked hang is bounded by the act's child process exit;
+in any pooled/long-lived design it is fatal without deadlines. Concretely: (1) every
+`page.close()`/`browserClose()` should be deadline-raced, (2) a tripped deadline should recycle
+the browser, not just the page, and (3) the meta-refresh fixture class belongs in any isolation
+test suite as the canonical wedge-inducer.
+
+The overall answer to "could testaro keep a browser across acts?": the observed isolation
+failures here were **rare, probabilistic wedge events with recognizable signatures**, not
+gradual deterministic leakage. That favors a middle path over browser-per-act: pool the browser,
+assert a cheap per-act canary (script-injection round-trip + expected globals), and recycle the
+browser only on a wedge signature or every N acts — the three-countermeasure pattern above,
+already exercised at ~1,200-page scale by this harness. The remaining unknown for production is
+whether *cross-page contamination* (state leaking between scanned pages, distinct from wedges)
+also occurs; this harness's same-tool-different-page design cannot see that class, so a pooled
+design should keep context-per-act (cheap) even if the browser is shared.
+
+## Explained failure classes (distinct from the cliff)
+
+- `contentType application/xml` fixtures: `document.createElement('script')` in an XML document
+  creates a null-namespace element that never executes — expected, benign, now visible via the
+  adapter's diagnostic error (content type, script chars, ready state).
+- "Resulting promise was garbage collected": fixtures that navigate (meta refresh) during the
+  in-page evaluate. All observed on `inapplicable` testcases.
+
+## Current best theory
+
+Not page count, not the axe interleave, not any single fixture so far: either (a) cumulative
+state that only the full 273-testcase real-page history builds up, or (b) a nondeterministic
+in-browser event (renderer/helper-process crash or OOM kill — the host was carrying ~31 GB of
+desktop Chrome RSS during the incident) that wedges `<script>`-element execution while leaving
+CDP `evaluate` execution intact. All fixtures being same-origin (`www.w3.org`) means Chromium packs
+them into shared renderer processes, which is consistent with one wedged process poisoning every
+subsequent same-origin page.
+
+## Production relevance (testaro browser-per-act)
+
+- The failure mode was **silent** — no exception anywhere; only an output-level check (expected
+  global absent) caught it. Any move away from browser-per-act needs a per-act canary assertion
+  of this kind, not just error handling.
+- Recycling every N acts (experiment 3) is so far sufficient as a guard and is the cheap middle
+  ground between browser-per-act and browser-forever; whether *context*-per-act (much cheaper
+  than browser launch) also resets the poisoned state is untested — worth adding
+  `--recycle-context` bisection if experiment 5 reproduces the cliff.
+- If experiment 5 comes back clean, the honest conclusion is: one observed environmental
+  incident in ~5,000 page-cycles, mitigated by periodic recycling — suggestive that testaro's
+  isolation bugs may likewise be rare wedge events rather than deterministic leakage, which would
+  argue for recycle-on-anomaly (canary-triggered) rather than always-fresh browsers.

package/validation/act/playwright-issue-draft.md

@@ -0,0 +1,73 @@
+# Playwright bug report — page.close() never settles after meta-refresh navigation
+
+**FILED 2026-08-22: <https://github.com/microsoft/playwright/issues/42366>**
+Minimal repro: `repro-metarefresh.js` in this directory (self-contained, local HTTP server).
+Chromium side: already tracked as <https://issues.chromium.org/issues/536385539> (pending code
+change 8251379); cross-linked in both directions 2026-08-22 — see `chromium-issue-draft.md`.
+
+---
+
+**Title:** [Bug]: page.close() hangs forever — Chromium's Target.closeTarget returns success:true
+without closing a target that is mid-commit in a client-side (meta refresh) navigation
+
+## System info
+
+- Playwright Version: 1.62.1 (latest at time of report)
+- Operating System: Linux (7.0.0-30-generic)
+- Browser: Chromium (bundled, HeadlessChrome/151.0.7922.34) — **Chromium only**; Firefox and
+  WebKit are unaffected (0/10 each in the same harness)
+- Other info: Node 24.14.1
+
+## Repro
+
+1. Serve a page with `<meta http-equiv="refresh" content="0; URL='/target.html'">` (immediate
+   client-side redirect; the W3C ACT-Rules bc659a "passed" fixtures are real-world examples).
+2. `page.goto(url, {waitUntil: 'load'})` — resolves.
+3. `page.evaluate(...)` — rejects with "Execution context was destroyed" (expected; the refresh
+   navigation fired mid-evaluate).
+4. `await page.close()` — **hangs on ~70–80% of rounds** (8/10, 7/10 across runs): the promise
+   never resolves and never rejects. `.catch()` never fires; a loop awaiting it freezes forever.
+
+## Root cause (from a `DEBUG=pw:protocol` trace of a hanging round)
+
+- Playwright sends `Target.closeTarget {targetId}`.
+- The browser replies `{"result":{"success":true}}`.
+- The target does not close: the meta-refresh navigation was mid-commit, and the same session
+  then emits the full lifecycle of the redirect destination — `Page.frameNavigated`,
+  `DOMContentLoaded`, `load`, paint events, `networkIdle` — all *after* the successful-looking
+  `closeTarget` response.
+- `Target.targetDestroyed` is never emitted; `page.close()` waits for it indefinitely.
+
+So Chromium acknowledges the close without performing it when the close races a navigation
+commit, and Playwright trusts the acknowledgment with no timeout or retry.
+
+The browser-side half is confirmed **without Playwright**: a raw-CDP repro (plain WebSocket, no
+client library) shows `Target.closeTarget` → `success:true` with no `Target.targetDestroyed`
+ever emitted and the target still listed in `Target.getTargets`, ~3/10 rounds. A Chromium bug is
+being filed in parallel (link when available). Playwright still has its own half: `page.close()`
+trusts the acknowledgment indefinitely — a deadline/retry (or routing default close through the
+`runBeforeUnload` path, which is immune) would make clients robust to the browser defect.
+
+## Matrix (10 rounds per cell, same repro)
+
+| | `close()` | `close({runBeforeUnload:true})` | `context.close()` |
+| --- | --- | --- | --- |
+| Chromium | **8/10 hang** | 0/10 | 0/10 |
+| Firefox | 0/10 | 0/10 | 0/10 |
+| WebKit | 0/10 | 0/10 | 0/10 |
+
+After a hang, `context.close()` still settles and destroys the page (**8/8 recoveries**) — the
+context teardown path is unaffected.
+
+## Expected behavior
+
+`page.close()` always settles — resolves once the page is gone, or rejects.
+
+**Workarounds** (verified): `page.close({runBeforeUnload: true})`; or race `close()` against a
+deadline and call `context.close()` on expiry (recovers reliably). Without a guard, a wedged
+browser's subsequent `newPage` can then fail with `Protocol error (Target.createTarget): Not
+supported` followed by "Target page, context or browser has been closed".
+
+Possibly related: #33806 (hangs while waiting for pending navigations) — different in that no
+dialog is involved and the acknowledged-but-not-performed `Target.closeTarget` is visible in the
+protocol trace.

package/validation/act/repro-cdp-raw.js

@@ -0,0 +1,105 @@
+// Playwright-free reproduction attempt: raw CDP over WebSocket (Node's
+// native WebSocket client). Question: does Chromium's Target.closeTarget
+// return {success:true} WITHOUT closing (no Target.targetDestroyed, target
+// still listed) when the close races a meta-refresh navigation commit?
+// If yes → browser-side contract violation, independent of Playwright.
+const http = require('http');
+const {spawn} = require('child_process');
+// Any Chromium binary works; defaults to Playwright's bundled one.
+const {chromium} = require('playwright');
+const CHROME = process.env.CHROME_PATH || chromium.executablePath();
+
+const pages = {
+  '/a.html': `<!DOCTYPE html><html lang="en"><head><title>a</title>
+    <meta http-equiv="refresh" content="0; URL='/target.html'"></head>
+    <body><p>redirecting</p></body></html>`,
+  '/target.html': `<!DOCTYPE html><html lang="en"><head><title>t</title></head>
+    <body><p>arrived</p></body></html>`
+};
+
+(async () => {
+  const server = http.createServer((req, res) => {
+    res.setHeader('content-type', 'text/html');
+    res.end(pages[req.url] || pages['/target.html']);
+  });
+  await new Promise(resolve => server.listen(0, resolve));
+  const base = `http://127.0.0.1:${server.address().port}`;
+
+  // Launch the same Chromium binary Playwright uses, but bare.
+  const chrome = spawn(CHROME, [
+    '--headless=new', '--remote-debugging-port=0', '--no-first-run', '--no-default-browser-check',
+    '--user-data-dir=/tmp/cdp-repro-profile'
+  ]);
+  const wsURL = await new Promise((resolve, reject) => {
+    let stderr = '';
+    chrome.stderr.on('data', chunk => {
+      stderr += chunk;
+      const match = stderr.match(/DevTools listening on (ws:\/\/\S+)/);
+      if (match) resolve(match[1]);
+    });
+    setTimeout(() => reject(new Error('no DevTools ws URL')), 15000);
+  });
+
+  const ws = new WebSocket(wsURL);
+  await new Promise(resolve => ws.onopen = resolve);
+  let nextId = 1;
+  const pending = new Map();
+  const events = [];
+  ws.onmessage = messageEvent => {
+    const message = JSON.parse(messageEvent.data);
+    if (message.id && pending.has(message.id)) {
+      pending.get(message.id)(message);
+      pending.delete(message.id);
+    }
+    else if (message.method) {
+      events.push(message);
+    }
+  };
+  const send = (method, params = {}, sessionId) => new Promise(resolve => {
+    const id = nextId++;
+    pending.set(id, resolve);
+    ws.send(JSON.stringify({id, method, params, ...(sessionId ? {sessionId} : {})}));
+  });
+  const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
+
+  await send('Target.setDiscoverTargets', {discover: true});
+  let contractViolations = 0;
+  const ROUNDS = 10;
+  for (let round = 0; round < ROUNDS; round++) {
+    const {result: {targetId}} = await send('Target.createTarget', {url: 'about:blank'});
+    const {result: {sessionId}} = await send('Target.attachToTarget', {targetId, flatten: true});
+    await send('Page.enable', {}, sessionId);
+    await send('Runtime.enable', {}, sessionId);
+    await send('Page.navigate', {url: `${base}/a.html`}, sessionId);
+    // Leave an evaluate in flight for the refresh navigation to destroy
+    // (mirrors the real-world trigger), then close during the commit window.
+    send('Runtime.evaluate', {
+      expression: 'new Promise(r => setTimeout(r, 100))',
+      awaitPromise: true
+    }, sessionId);
+    await wait(30 + (round % 5) * 15);
+    events.length = 0;
+    const closeReply = await send('Target.closeTarget', {targetId});
+    const success = closeReply.result && closeReply.result.success;
+    await wait(3000);
+    const destroyed = events.some(
+      e => e.method === 'Target.targetDestroyed' && e.params.targetId === targetId
+    );
+    const {result: {targetInfos}} = await send('Target.getTargets');
+    const stillListed = targetInfos.some(t => t.targetId === targetId);
+    const verdict = success && ! destroyed && stillListed ? 'CONTRACT VIOLATION'
+      : success && destroyed ? 'closed properly'
+        : `other (success=${success} destroyed=${destroyed} listed=${stillListed})`;
+    console.log(`round ${round}: closeTarget success=${success}, targetDestroyed=${destroyed}, stillListed=${stillListed} → ${verdict}`);
+    if (verdict === 'CONTRACT VIOLATION') {
+      contractViolations++;
+      // Clean up the orphan so rounds stay independent.
+      await send('Target.closeTarget', {targetId});
+      await wait(500);
+    }
+  }
+  console.log(`${contractViolations}/${ROUNDS} rounds: success:true with target neither destroyed nor removed`);
+  chrome.kill();
+  server.close();
+  process.exit(0);
+})();

package/validation/act/repro-metarefresh.js

@@ -0,0 +1,65 @@
+/*
+  © 2026 Jeff Witt.
+
+  Licensed under the MIT License. See LICENSE file at the project root or
+  https://opensource.org/license/mit/ for details.
+
+  SPDX-License-Identifier: MIT
+*/
+
+/*
+  repro-metarefresh.js
+  Minimal reproduction: page.close() intermittently NEVER SETTLES (neither
+  resolves nor rejects) when the page performed a meta-refresh(0) navigation
+  that interrupted an in-flight evaluate. See playwright-issue-draft.md.
+  Observed on playwright 1.62.1, Chromium headless: ~50% of rounds hang.
+  Run from the repository root: node validation/act/repro-metarefresh.js
+*/
+
+const http = require('http');
+const {chromium} = require('playwright');
+
+const pages = {
+  '/a.html': `<!DOCTYPE html><html lang="en"><head><title>a</title>
+    <meta http-equiv="refresh" content="0; URL='/target.html'"></head>
+    <body><p>redirecting</p></body></html>`,
+  '/target.html': `<!DOCTYPE html><html lang="en"><head><title>t</title></head>
+    <body><p>arrived</p></body></html>`
+};
+
+// Reports whether a promise settles within ms.
+const settles = (promise, ms) => Promise.race([
+  promise.then(() => 'resolved').catch(() => 'rejected'),
+  new Promise(resolve => setTimeout(() => resolve('NEVER SETTLED'), ms))
+]);
+
+(async () => {
+  const server = http.createServer((req, res) => {
+    res.setHeader('content-type', 'text/html');
+    res.end(pages[req.url] || pages['/target.html']);
+  });
+  await new Promise(resolve => server.listen(0, resolve));
+  const base = `http://127.0.0.1:${server.address().port}`;
+  const browser = await chromium.launch();
+  const context = await browser.newContext();
+  let hangs = 0;
+  const ROUNDS = 10;
+  for (let round = 0; round < ROUNDS; round++) {
+    const page = await context.newPage();
+    await page.goto(`${base}/a.html`, {waitUntil: 'load'});
+    // An evaluate for the meta refresh to interrupt (it rejects with
+    // "Execution context was destroyed" — expected and irrelevant).
+    await page.evaluate(
+      () => new Promise(resolve => setTimeout(resolve, 100))
+    ).catch(() => {});
+    const outcome = await settles(page.close(), 10000);
+    console.log(`round ${round}: page.close() ${outcome}`);
+    if (outcome === 'NEVER SETTLED') {
+      hangs++;
+    }
+  }
+  console.log(`${hangs}/${ROUNDS} rounds hung`);
+  await Promise.race([browser.close(), new Promise(r => setTimeout(r, 5000))]);
+  server.close();
+  process.exit(hangs ? 1 : 0);
+})();