Skip to content

chore(coverage): istanbul instrumentation for the trace viewer and html reporter - #42785

Merged
Yury Semikhatsky (yury-s) merged 7 commits into
microsoft:mainfrom
yury-s:coverage-service-workers
Sep 19, 2026
Merged

Yury Semikhatsky (yury-s) merged 7 commits into
microsoft:mainfrom
yury-s:coverage-service-workers

Conversation

@yury-s

@yury-s Yury Semikhatsky (yury-s) commented Sep 18, 2026

Copy link
Copy Markdown
Member

Summary

  • vite plugin behind PWTEST_COVERAGE instruments the sources under packages/, so the trace viewer and html reporter tests report their own coverage through tracing
  • rolls the stable test runner to 1.64.0-alpha-2026-09-18, the first with tracing coverage, so the html reporter tests need no collector of their own
  • the trace viewer service worker serves its own counters from a /coverage route that only exists in instrumented builds
  • the product coverage feature stays page-only: only Chromium exposes a service worker execution context, and worker counters die with every termination

Why not vite-plugin-istanbul: it runs after the TypeScript and JSX transforms, so the recorded positions refer to the emitted code and only a report stage that applies the embedded inputSourceMap can map them back. Our reporter does not, so the plugin here instruments the original sources instead.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

…ml reporter

Instrument the sources under packages/ with a vite plugin behind
PWTEST_COVERAGE and record the coverage of the trace viewer and html
reporter pages through tracing. The stable test runner is rolled to
1.64.0-alpha-2026-09-18, the first with the tracing coverage, so the
html reporter tests need no collector of their own.

The trace viewer service worker has its own global and its own counters.
The instrumented build serves them from a /coverage route of the worker,
gated on the __PW_COVERAGE__ define that the istanbul plugin sets, so a
normal build carries neither the route nor a counter reference. The tests
fold the worker delta into window.__coverage__ through the page before
the page is collected.

Only applyPlaywrightAttributes in the snapshot renderer is skipped with an
istanbul hint, since its source is stringified into the snapshot where the
counters do not exist.

The product feature does not follow for now. Only Chromium exposes a
service worker execution context, Firefox's juggler has no service worker
targets and WebKit's automation session attaches to page and frame targets
only, so both would need a browser patch. Worker counters also die with
every termination and there is no unload hook to stash them, so a generic
collector would be Chromium-only and lossy.
The plugin imports it directly instead of resolving it at run time, and
the install instructions go away.
…strument

The schema defaults are stage-4 syntax that the parser enables anyway,
so only the typescript and jsx plugins remain and the local declarations
go away.
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

The plugin no longer checks the environment or defines __PW_COVERAGE__,
the worker's coverage route answers only when counters exist.
@github-actions

Copy link
Copy Markdown
Contributor

Test results for "tests 1"

5 flaky ⚠️ [chromium-library] › library/video.spec.ts:690 › screencast › should capture full viewport `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/browsercontext-page-event.spec.ts:173 › should work with Ctrl-clicking `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-page] › page/page-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node20`

52020 passed, 1250 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

Test results for "MCP"

3 failed
❌ [chromium] › mcp/cli-webmcp.spec.ts:135 › webmcp-list stitches tools across frames @mcp-macos-latest-chromium
❌ [msedge] › mcp/annotate.spec.ts:291 › should enter annotate mode on fresh dashboard.tsx mount with -s --annotate @mcp-windows-latest-msedge
❌ [msedge] › mcp/annotate.spec.ts:316 › should annotate via direct browser_annotate MCP call @mcp-windows-latest-msedge

8689 passed, 1474 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

🟡 Two known flakes, one I can't clear

Hi, I'm the Playwright bot and I took a look at the failing MCP run. The two msedge annotate failures are a documented flake on mcp-windows-latest-msedge. The WebMCP frame test on macOS is the open one — it has failed on three of this PR's shas and on nothing else in the CI results db.

Details

This PR is coverage instrumentation. The istanbul vite plugin is registered only when PWTEST_COVERAGE is set, which CI never sets; the rest is a code move of takeCounters/takeBranchCounters from coverageScript.ts into @isomorphic/istanbulCoverage, a /coverage route on the trace viewer service worker, an /* istanbul ignore next */ comment in snapshotRenderer.ts, and test-side config plus the stable-test-runner roll. The MCP CLI tests import none of it — tests/mcp/fixtures.ts pulls from tests/config/ but not traceViewerFixtures.ts. The tests 1 run has no failures to triage: 5 within-run flakes, all rescued on retry.

Pre-existing flake / infra

Uncertain

  • [chromium] › mcp/cli-webmcp.spec.ts:135 › webmcp-list stitches tools across framesExpected substring: "Found 2 WebMCP tool(s)", got Found 1, so only one frame's tools were stitched in. It reads like a cross-frame registration race, but I can't call it a flake: on mcp-macos-latest-chromium the test has 10 runs in the db, and the only red ones are this PR's — fabe18a1, d29eeae5, and now 3994ed5. The sibling :188 › webmcp-call disambiguates same-name tools in identical same-origin frames also went red on mcp-macos-latest-chrome on fabe18a1, again only here. Three shas is a real pattern, but I see no mechanism in this diff that reaches the WebMCP frame path, and the test is young (first db result 2026-09-11), so a newly flaky macOS test fits the evidence just as well. What would settle it: a rerun of the MCP job on this sha, or one run of mcp/cli-webmcp.spec.ts on main against the macOS bots.

Triaged by the Playwright bot - agent run

@yury-s
Yury Semikhatsky (yury-s) merged commit 07f1a61 into microsoft:main Sep 19, 2026
43 of 45 checks passed
@yury-s
Yury Semikhatsky (yury-s) deleted the coverage-service-workers branch September 19, 2026 01:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants