chore: upgrade Chromium from v126 to v143 for asset discovery

[Manoj-Katta]

Chromium v126 → v143 upgrade (PR #2187)

This PR upgrades the bundled Chromium binary that @percy/core uses for asset discovery from v126.0.6478.184 → v143.0.7499.169, to match the version percy-renderer ships server-side.

The version jump crosses 17 major Chrome versions including:

• Chrome 128 — old-headless → new-headless rewrite (blog)
• Chrome 130 — Local Network Access opt-in
• Chrome 132 — --headless=old deleted entirely
• Chrome 143 — Local Network Access default-on, malformed Content-Length leniency, PlzDedicatedWorker default

Many "regressions" we hit are not bugs — they are intentional Chrome behaviors that old headless quietly didn't enforce. This document walks each one, the diagnostic story behind it, and the fix.

TL;DR for reviewers: Production-code changes concentrated in network.js (with smaller diffs in browser.js and install.js) covering 9 categories of v143 behavior change. The network.js changes are layered: (a) Chrome 128 site isolation and v143 launch-flag work in browser.js; (b) malformed Content-Length pre-abort and the worker-script direct-fetch fallback with size/origin/timeout safety nets in network.js; (c) test coverage for every new branch including the deterministic captureResourceDirectly catch test that closes the L755 gap. Per ce:review, 11 must-fix/should-fix items are applied; 5 reviewer comments are documented as deferred with reasons.

Section 1 — What Chrome 143 changed, and what we did for each

1.1. Site isolation became default-on (Chrome 128)

What changed: Cross-origin sub-resources and worker scripts now run in separate renderer processes by default. --disable-site-isolation-trials only affected opt-in trials, not the baseline-on behavior.

How it broke Percy: Percy's CDP Fetch.enable and Network.enable are attached to the page session. Events on a sibling renderer process don't reach those listeners → worker fetches and some cross-origin sub-resources were silently uncaptured.

What we did: Added IsolateOrigins,site-per-process to the --disable-features= launch flag (browser.js). Keeps cross-origin sub-resources in the same renderer process, matching v126 old-headless behavior.

Risk: None for Percy's use case. CORS/CORB/ORB enforcement on actual cross-origin internet hosts is preserved — only Chrome's process-isolation is relaxed.

1.2. HTTPS-first auto-upgrade in headless (Chrome 143)

What changed: Chrome 143 silently auto-upgrades any HTTP navigation to HTTPS. If HTTPS isn't reachable, Chrome blocks navigation with net::ERR_BLOCKED_BY_CLIENT.

How it broke Percy: Customers running asset discovery against HTTP URLs (local dev servers, CI environments, staging) would see silent navigation failures.

What we did: Added HttpsFirstBalancedModeAutoEnable to --disable-features=. HTTP navigation proceeds normally.

Risk: None — Percy is a tool, not a browser. Users intend to load the URL they pass in.

1.3. Local Network Access checks default-on (Chrome 143)

What changed: Pages fulfilled via Fetch.fulfillRequest (Percy's domSnapshot root-document path) are treated as an external context by Chrome's LNA gating. Sub-resource requests to localhost, 127.0.0.1, or RFC 1918 private addresses are blocked with corsError = LocalNetworkAccessPermissionDenied.

How it broke Percy: 12 cross-origin and auto-domain-validation discovery tests failed. Percy's logger swallowed the actual Chrome error — visible only via raw CDP. The wrong hypothesis (a planned dual-stage Fetch interception refactor) would have wasted weeks.

Diagnostic story: Wrote a standalone raw-CDP Node script that bypassed Percy entirely and replicated the exact Fetch.fulfillRequest flow. The probe surfaced LocalNetworkAccessPermissionDenied. Cross-referenced with Chrome's LNA spec.

What we did: Added LocalNetworkAccessChecks to --disable-features=. Narrower than --disable-web-security — preserves CORS/CORB/ORB on real internet hosts, only relaxes Chrome's loopback/private-network gating, which is exactly what asset discovery needs.

Risk: None for headless asset discovery. The renderer side doesn't use this flag.

1.4. Malformed Content-Length no longer triggers Chrome self-abort (Chrome 143)

What changed: In v126, Chrome's HTTP parser detected malformed Content-Length (NaN, non-numeric) and dropped the connection. Network.loadingFailed fired and Percy logged the failure. In v143, Chrome is lenient — it waits indefinitely for body bytes that never come. No event reaches Percy.

How it broke Percy: A page with <link href="bad.css"> (where the server returns malformed CL) would hang. Page.lifecycleEvent name=load never fires. Page.navigate({waitUntil:'load'}) times out at 30s, retries 3 times → 93s of dead air, then snapshot fails.

Diagnostic story: Reproduced the 93s timeout. Added per-event CDP tracing in network.js. Confirmed Network.responseReceived fired (status=200, headers received) but Network.loadingFinished and Network.loadingFailed never fired. The connection was hanging in Chrome's network stack.

What we did (5 pieces, all in network.js):

1. Opt into response-stage Fetch interception via interceptResponse: true on Fetch.continueRequest. Chrome now pauses every intercepted request a second time once response headers are received (but before body bytes stream).

2. Add _handleResponsePaused to inspect Content-Length at the response stage. If tooLarge or malformed, call Fetch.failRequest({errorReason: 'Aborted'}) proactively — Chrome stops waiting, <link> resolves as failed, page load fires.

3. Two helper functions (headersArrayToObject, inspectContentLength) at module scope for clean inspection.

4. Lifecycle ordering: Fetch.failRequest BEFORE _forgetRequest. v126's malformed-CL handling was implicit (Chrome auto-aborted); v143 forces us to call Fetch.failRequest explicitly. If our failRequest call itself throws (transient CDP error, target detach race), running _forgetRequest first would leak Chrome's Fetch state — Percy thinks the request is done, but Chrome's interception is still paused indefinitely. We now finalize the disposition first, only forgetting the request after. On unrecognized errors, a last-resort Fetch.continueResponse attempts to un-pause Chrome so it doesn't leak.

5. Observability for stuck-snapshot diagnostics — currently at debug, telemetry follow-up tracked. Unknown errors in _handleResponsePaused's failRequest catch and _continueResponse's catch stay at log.debug. We initially promoted these to log.warn for default-loglevel visibility, then reverted (commit 334f0621) because routine Session closed / Target closed lifecycle races fired these catches and the warn noise drowned legitimate signals. The right home for this signal is structured instrumentation telemetry rather than user-facing logs; tracking that as a separate follow-up so customer logs stay quiet on routine teardowns.

Pattern established: Fetch.failRequest is used only when Percy asserts a failure (our oversized-CL abort). For errors Chrome already reports, we use Fetch.continueResponse to defer to Chrome's natural loadingFailed flow — this preserves Chrome's specific errorText (e.g. net::ERR_EMPTY_RESPONSE) instead of synthesizing a generic net::ERR_FAILED (which Percy's asset_load_missing instrumentation explicitly filters as noise).

Side benefit: Pre-fix, Percy's MAX_RESOURCE_SIZE check inside saveResponseResource ran after Chrome had already buffered the full body. Our new check fires before the body streams — saves bandwidth and memory, and unsticks the page render faster. This was a latent inefficiency in v126 too; v143 forced us to fix it.

Cost: Every Fetch-intercepted request now does one extra CDP roundtrip. Sub-millisecond on localhost websocket. Puppeteer and Playwright use the same dual-stage interception pattern.

1.5. PlzDedicatedWorker — dedicated worker scripts disappear from CDP (Chrome 143)

What changed: Chrome 143 made PlzDedicatedWorker the default (Chromium issue 40093136 — "Implement browser-initiated dedicated worker script load"). Dedicated worker scripts are now fetched in the browser process via WorkerScriptFetcher, not in the renderer URLLoader proxy chain. The renderer-side URLLoader proxy is what historically emitted Network.responseReceived for worker scripts "for free." That path is now bypassed.

The precise mechanism (verified against Chromium source): Under PlzDedicatedWorker, DevTools instrumentation for the worker-script fetch is handled by content/browser/devtools/devtools_instrumentation.cc. That file has hand-coded hooks for the worker path: OnWorkerMainScriptRequestWillBeSent (emits Network.requestWillBeSent) and OnWorkerMainScriptLoadingFailed (emits Network.loadingFailed). There is no corresponding OnWorkerMainScriptResponseReceived hook. Service workers have one (OnServiceWorkerMainScriptFetchingFailed → network_handler->ResponseReceived(...)); dedicated workers don't. So Network.responseReceived is never emitted on any CDP session for a successful dedicated-worker main-script fetch — it's a Chromium instrumentation gap, not a routing problem.

The NetworkServiceDevToolsObserver attached to the worker-script URLLoaderFactory is bound to the page frame's devtools token (see content/browser/worker_host/worker_script_fetcher.cc — MakeSelfOwned(creator_render_frame_host->GetDevToolsFrameToken().ToString())), which is why the page session sees requestWillBeSent. The loadingFinished that does fire on the worker session arrives via a separate path — the worker target's own NetworkHandler, created at auto-attach by content/browser/devtools/dedicated_worker_devtools_agent_host.cc's AttachSession, receives completion from the renderer once the worker is alive — but that handler never received requestWillBeSent or responseReceived from the browser-side fetch, so Network.getResponseBody against it returns "no resource with given identifier found."

Auto-attach (Target.setAutoAttach) is not the cause — it merely makes the asymmetry visible because there's a worker session to receive loadingFinished. A single-session debugger sees the same loss of responseReceived.

How it broke Percy: Two layered failures.

Failure A — idle() hangs forever. Percy's _handleLoadingFinished awaits Network.responseReceived unconditionally. Since Chromium never emits that event for the worker script, the await blocks forever → the request stays in #requests → idle() never returns → snapshot hits Page.TIMEOUT × 3 retries = 93s.

Failure B — Worker bytes never reach CDP. Even after we time out and clean up #requests, the renderer (server-side) still needs the worker.js bytes to construct the Worker at render time. Neither the page session's NetworkHandler nor the worker session's NetworkHandler ever stored the body, so Network.getResponseBody returns "no resource with given identifier found" on both sessions.

Diagnostic story:

• Wrote a standalone raw-CDP Node script that spawns v143 Chromium, navigates to a worker page, logs every Network/Fetch/Target event across all sessions, and tries Network.getResponseBody on each session that emitted events. Confirmed: responseReceived is absent on every session; loadingFinished fires on the worker session with the page's requestId (= the worker token); getResponseBody returns "no resource with given identifier found" everywhere.
• Confirmed against Chromium source: no OnWorkerMainScriptResponseReceived hook exists in content/browser/devtools/devtools_instrumentation.cc.
• Cross-checked with Playwright issue #31747 and PR #35692, and Puppeteer PR #13752 — both upstream projects independently hit the same gap.

What we did (in network.js):

1. RESPONSE_RECEIVED_TIMEOUT = 2000 — module-scope named constant. Cap the responseReceived await in _handleLoadingFinished with a Promise.race against a 2-second timer. Worker scripts wake up the handler instead of hanging it. Comment notes the cumulative N*2s worst case so future readers can reason about cost.

2. Debug log when the timeout fires (Skipping resource: responseReceived not received within 2000ms - <url>). Asserted in captures requests from workers so a regression is observable — if a future Chrome restores the v126 lifecycle, the negated assertion will fail and tell us to remove the workaround.

3. captureResourceDirectly fallback (renamed from captureScriptDirectly — the function captures any allowlisted resource that fell through to direct fetch, not just worker scripts). When the timeout fires and the URL is in allowedHostnames AND NOT in disallowedHostnames, fetch the bytes directly via Node HTTP (makeDirectRequest, the same helper used for fonts since v126). Save them as a Percy resource with mimetype derived from the URL extension via mime.lookup().

4. DIRECT_FETCH_TIMEOUT = 5000 — module-scope constant. Wraps the makeDirectRequest call inside captureResourceDirectly in Promise.race against a 5-second timer. Caps the wall-clock cost if a worker host accepts the TCP connection but stalls. Pre-fix worst case was ~30s (networkIdleWaitTimeout); post-fix is ~7s (RESPONSE_RECEIVED_TIMEOUT + DIRECT_FETCH_TIMEOUT).

5. Size guard + real HTTP status in captureResourceDirectly. makeDirectRequest now returns { body, status } via the makeRequest callback. The fallback rejects bodies over MAX_RESOURCE_SIZE (25 MB) — matching saveResponseResource's guard — to keep the WebSocket payload safe. The Percy resource records the real HTTP status from the direct fetch instead of a hardcoded 200. Font path call site updated to destructure { body }.

6. Disallowedhostnames precedence at the fallback gate. The gate in _handleLoadingFinished now mirrors sendResponseResource's pattern — checks disallowedHostnames first, allowedHostnames second. Customers who explicitly blocklist an internal host won't see Percy's Node fallback bypass that gate. A debug log fires when the fallback is skipped due to hostname gating so the silent-skip is observable.

7. Same-origin Authorization in makeDirectRequest. Browser's URLLoader origin-scopes Basic auth automatically; our Node fallback didn't. Extracted as an exported shouldAttachAuth(authorization, requestUrl, snapshotUrl) pure helper that compares the target URL's origin against network.meta?.snapshotURL's origin and only returns true when both URLs parse and origins match. Malformed URLs return false defensively. Prevents customer credentials leaking to redirected third-party origins, and makes the same-origin / cross-origin / malformed-URL branches unit-testable without /* istanbul ignore */ markers.

8. makeDirectRequest reads cookies from the page session, not the triggering session. When captureResourceDirectly is called from _handleLoadingFinished bound to the worker session (v143 worker-script case), Network.getCookies on that session throws "Internal error" because the worker session's NetworkHandler has only a partial Network domain. Extracted as an exported pickCookieSession(network, session) helper that returns network.page.session (the top-level page session, full Network domain) when available and falls back to the triggering session otherwise. Both branches of the ?? are unit-testable via the helper. A defensive try/catch with empty-cookies fallback remains for the unlikely case the page session's Network.getCookies is also unavailable (e.g., browser closing mid-snapshot).

Why the hostname gate (not type gate): v143 PlzDedicatedWorker reports the worker fetch with resourceType: 'Other', not 'Script'. A strict type check would miss the case. Gating on allowedHostnames scopes the fallback to URLs the snapshot would have captured anyway, regardless of Chrome's internal classification.

1.6. HTML attribute-value serialization escapes < and > (Chrome 128+)

What changed: Chrome 128's new-headless serializes HTML attribute values per the HTML5 spec, entity-escaping < and >. So <iframe srcdoc="<p>Foo</p>"> serializes as <iframe srcdoc="&lt;p&gt;Foo&lt;/p&gt;">. Both render identically.

How it broke Percy: One test (runs the execute callback in the correct frame) asserted the literal <p>Foo</p> in serialized iframe srcdoc.

What we did: Widened the regex to accept either form. No production code change.

1.7. Chrome 128+ auto-fetches /favicon.ico on every navigation

What changed: New headless mode auto-fetches favicons. Old headless never did.

How it broke Percy: Several discovery tests asserted exact server.requests counts or captured[i] indices. Phantom /favicon.ico entries shifted everything.

What we did: Two test-helper changes (test/helpers/server.js):

1. Filter /favicon.ico out of the server.requests log
2. Reply HTTP 204 by default for /favicon.ico so it doesn't enter the snapshot resource list

Tests that explicitly want favicon capture (added in 890883ad, 98f5a4e2) register their own server.reply('/favicon.ico', ...) override.

Note for next commit: the 204-default approach masks v128+ behavior instead of acknowledging it. A pending principled refactor will revert to a realistic test fixture and update affected tests to expect the auto-favicon-fetch in their assertions.

1.8. Browser-launch failure path varies by platform (Chrome 143)

What changed: Some args we used to test the "browser failed to launch" code path no longer cause Chrome to exit on all platforms. v143 Chrome with --version exits cleanly on Linux/macOS but keeps running on Windows; v126's pattern was Windows-friendly via --remote-debugging-port=null.

What we did: browser.js now passes a real Error to its rejection handler (one shape across code paths). The failing-launch test uses --version on Linux/macOS and --remote-debugging-port=null on Windows so each runner exercises the handleExitClose code path.

1.9. Auth dialog cancellation in headless (fundamental v143, NOT fixed)

Observed: When Chrome 143 cancels an HTTP basic auth dialog in headless mode, the page's load event never fires. Page.navigate({waitUntil:'load'}) times out at 30s.

Impact: The does not capture without auth credentials test still takes ~1m34s in v143 (vs ~1s in v126). Test still passes; just slowly.

Why not fixed: This is fundamental Chrome 143 headless behavior — there's no graceful path on Percy's side. Real customers running asset discovery against auth-protected URLs without credentials would hit the same delay. Documented as known.

Section 2 — Other plumbing changes (not Chrome-behavior driven)

2.1. CI cache-key bump

.github/.cache-key counter incremented. Forces CI to re-download the v143 Chromium binary instead of reusing the cached v126.

⚠️ Note for future Chromium upgrades: This bump was missed for v96, v123, and v126 upgrades in prior PRs. CI for those upgrades may have silently run against the cached old binary, producing false-green CI signals. Going forward this should be a mandatory step. Consider a pre-commit hook or PR template checklist item.

2.2. Updated sec-ch-ua header

In network.js, the hardcoded sec-ch-ua HTTP request header bumped from v123 → v143. Used only by makeDirectRequest (direct HTTP for fonts and the new worker fallback). Header should match the bundled binary's version.

Deferred: Reviewer ce:review (P2 #6) flagged that the version literal will silently desync on the next Chrome bump. The whole makeDirectRequest header block has multiple hardcoded values (sec-fetch-dest: 'font' is wrong for worker scripts; sec-ch-ua-platform: '"macOS"' is wrong on Linux/Windows). Deferring a full audit rather than fixing one literal in isolation.

2.3. install.js revisions

Bumped the per-platform Chromium revision numbers in install.js. Each revision is the nearest chromium-snapshots entry to v143.0.7499.169 for that platform.

Documented the picking-procedure in inline comments so future upgrades don't have to re-derive it.

Section 3 — References

• Chrome release notes: v143, v130 LNA, Headless rewrite
• PlzDedicatedWorker: Chromium issue 40093136, Playwright issue #31747, Playwright PR #35692, Puppeteer PR #13752
• Chromium source (verified — see §1.5):
  • content/browser/worker_host/worker_script_fetcher.cc — NetworkServiceDevToolsObserver bound to the page frame's devtools token
  • content/browser/devtools/devtools_instrumentation.cc — OnWorkerMainScriptRequestWillBeSent / OnWorkerMainScriptLoadingFailed present; no OnWorkerMainScriptResponseReceived
  • content/browser/devtools/dedicated_worker_devtools_agent_host.cc — AttachSession creates the worker session's NetworkHandler that later receives loadingFinished
• CDP Fetch domain: https://chromedevtools.github.io/devtools-protocol/tot/Fetch/

[this-is-shivamsingh]

commented :}}

[bhokaremoin]

Reviewed end-to-end — the diagnostics, Chromium-source citations, and per-feature rationale in this PR are well above the bar, and the dual-stage Fetch interception + worker-script direct-fetch fallback are well-considered. Twelve findings inline:

Blocking

• C1 — CI is red. network.js:753 (the captureScriptDirectly catch-block log.debug) is the only uncovered line in src/ after 2d48f20 dropped its test. The repo enforces 100% global coverage. Either re-add the test (stubbing makeDirectRequest) or /* istanbul ignore next */ the catch consistent with this file's pattern.

Worth addressing in this PR

• C2 — Add an inline comment in _handleResponsePaused explaining when #requests.get(requestId) returns undefined (SW-fulfilled? redirect race?). The behavior is correct; the rationale is invisible.
• C3 — URL normalization mismatch in _handleResponsePaused: tracked path uses originURL (normalized), untracked falls back to raw event.request.url. Telemetry will see two different URLs for the same resource.
• C4 — Extract the 6-feature --disable-features= list into a named DISABLED_FEATURES array with one comment per flag noting the Chrome version that introduced the need. Will pay off massively at the next Chrome upgrade.
• C6 — Move the favicon "band-aid" follow-up commitment from the PR body into a TODO(PPLT-4214 follow-up): comment in server.js so the cleanup is discoverable.
• C8 — Fetch.failRequest catch logs at debug — invisible at default loglevel. A stuck-snapshot production incident would have no signal. Log non-race errors at warn.
• C11 — Confirm darwin: 1536380 vs darwinArm: 1536376 weren't swapped; the asymmetry is plausible but worth a quick double-check against the snapshot index.
• C12 — Confirm that silently skipping worker scripts from non-allowedHostnames hosts is intended (default-config users will lose CDN worker captures after this upgrade vs. v126). If yes, add a distinct debug log so the skip is observable.

Polish / defer to follow-up

• C5 — 100ms → 1000ms waitForTimeout bump in percy.test.js papers over a timing race rather than fixing it. The firstCallResolver pattern used elsewhere in this PR would be deterministic.
• C7 — parseInt(rawValue) → parseInt(rawValue, 10) to match repo convention.
• C9 — One-line expansion of the RESPONSE_RECEIVED_TIMEOUT comment documenting the N × 2s cumulative-timeout worst case.
• C10 — Mirror the cookie-less direct-fetch caveat into user-facing release notes so customers running auth-gated dedicated workers aren't surprised by diffs.

Overall: solid work. Once C1 is resolved and the C2–C4/C6/C8/C11/C12 items are addressed (or explicitly deferred with rationale), this is ready to merge.

[amandeepsingh333]

Excellent write-up — the diagnostic story for PlzDedicatedWorker and the Chromium-source citations are the kind of context that makes this reviewable at all. The layered fix (response-stage interception for malformed CL + 2s responseReceived timeout + direct-fetch fallback with origin-scoped auth) is the right shape.

Non-test concerns, ordered by severity:

Should-fix (correctness/operational):

1. install.js — darwinArm: '1536376' is identical to win64. Likely a copy-paste error; ARM macOS should have its own snapshot.
2. network.js — sec-ch-ua-platform: '"macOS"' is hardcoded and sent from Linux/Windows runners. Servers doing content negotiation on this header will misbehave. PR body marks this "deferred" but it's a real signal.
3. network.js#_continueResponse — PR body claims "Production observability via log.warn" but the code uses log.debug. Either fix code or fix the description.
4. captureResourceDirectly mimetype default application/javascript — assumes worker-scripts. For non-worker direct fetches that hit this path (font fallback was the original caller), an extensionless URL silently gets mistyped as JS.

Nice-to-have (clarity / defensive):
5. browser.js comma-bundled --disable-features list mixes process-isolation (security boundary) with HTTPS-first and LNA. Worth a comment per disabled feature explaining why it's safe in headless asset discovery and not safe to copy to any non-headless code path.
6. shouldAttachAuth defensively return false when meta?.snapshotURL is undefined — confirm meta.snapshotURL is guaranteed populated in all entry paths; otherwise existing customers using network.authorization with the font fallback may silently lose auth.
7. RESPONSE_RECEIVED_TIMEOUT cumulative N*2s — comment acknowledges it but no hard cap. A pathological page with many worker fetches that all timeout could compound. Worth a per-snapshot ceiling.

I deliberately skipped test files per your request. Notes inline.

[amandeepsingh333]

Have we tested locally?

[bhokaremoin]

Approving — all 12 findings from my original review are addressed (9 fixed in code, 2 defended with reasoning captured in-thread, 1 explicit deferral per pre-approval). The second reviewer's pass added 4 more genuine improvements (mimetype fallback, DISABLED_FEATURES extraction, PR-body/code mismatch, ARM macOS revision verified). All 26 review threads are resolved. CI is green across all 44 checks including the previously-red Test @percy/core coverage gate.

The layered v143-compat work (dual-stage Fetch interception, RESPONSE_RECEIVED_TIMEOUT + DIRECT_FETCH_TIMEOUT worker-script fallback, shouldAttachAuth same-origin guard, pickCookieSession page-session preference) is well-considered and the diagnostic write-ups in the PR body are exemplary.

Remaining deferred work is properly externalized:

• PPLT-4215 — sec-ch-ua-platform, sec-fetch-dest, optional-chain UA fallback (font-asset capture regression follow-up)
• Stuck-snapshot observability → structured instrumentation telemetry follow-up
• CHANGELOG entry for cookie-less worker-script fallback → release time
• Per-instance cumulative-timeout cap → telemetry-driven, only if a customer hits it

None of those are correctness regressions vs. v126. Ship it.