Chrome SW respawn coverage unprovable under CfT CDP automation (restore real coverage)

[perdrizat]

Summary

The Chrome service-worker kill/respawn coverage cannot demonstrate a real respawn under Chrome for Testing (CfT) in headless CDP automation, so it was passing vacuously. Per audit 2026-07-16 finding M2, the checks were reworked to be honest (verify what's verifiable; report the respawn gap informationally) — this issue tracks restoring genuine Chrome respawn coverage if a technique is found.

What was happening

tests/e2e-chrome/_tools/smoke.mjs and tests/e2e/_helpers.ts (restartChromeServiceWorker, used by tests/e2e/event-page-lifecycle.test.ts) killed the SW via Target.closeTarget, then asserted a respawn by waiting for "a service_worker target to exist" — which matched the same never-killed worker on any timing where teardown/respawn overlapped, reporting a vacuous respawn.

What was probed (2026-07-17, CfT 151.0.7922.34)

• Target.closeTarget does terminate the worker (its target disappears from browser.targets() within ~500ms). ✓ verifiable.
• The worker then never respawns: not on a content-page navigation, not on opening the extension's own newTab.html, not on a runtime.sendMessage from an open extension page. It stays dead.
• Chrome exposes no controllable idle-suspension analogue to Firefox's extensions.background.idle.timeout, so the natural suspend/respawn cycle can't be induced in automation either.

Conclusion: under CfT headless CDP automation, Target.closeTarget on an MV3 SW is terminal — a genuine kill+respawn round-trip is not achievable with the current technique.

What was changed (audit M2 remediation)

• smoke.mjs: replaced the vacuous "SW respawn: target reappears" check with a real "SW kill: target terminates on CDP close" check; kept the storage.session durability check (a value written before the kill is still readable after — the property pendingCaptures relies on); the respawn gap is now an informational ~ note, not a pass and not a gate-blocking fail.
• _helpers.ts restartChromeServiceWorker: now detects a genuinely-new worker instance by targetId (not "any worker exists"); on this CfT it can't produce one, so event-page-lifecycle.test.ts's Chrome respawn branch is skipped with a documented reason rather than passing vacuously.

Current real coverage of respawn hygiene (not lost)

• Firefox event-page-lifecycle.test.ts genuinely suspends/respawns the background via the idle-timeout pref, on the same background code Chrome runs (routed through the api seam).
• tests/integration/event-page-resilience.test.ts, db-wake-race.test.ts — respawn-hygiene invariants (synchronous listener registration, IDB reconnect, storage.session-backed pendingCaptures).

The only gap is a Chrome-only respawn regression in the narrow api-seam divergences.

Restore criteria

Reinstate a genuine Chrome respawn assertion (new-targetId based) if any of these become available:

• a CfT/CDP command that suspends-not-terminates an MV3 SW, or a post-closeTarget wake that Chrome honors in automation;
• a headless CfT build whose Target.closeTarget leaves the worker eligible for event-driven respawn;
• a supported puppeteer API for MV3 SW lifecycle control.