chore: upgrade Chromium from v126 to v143 for asset discovery

[Manoj-Katta]

Upgrade bundled Chromium from v126.0.6478.184 to v143.0.7499.169 to match the renderer browser version. This is a 17-major-version jump that crosses Chrome 128's switch from old-headless to new-headless mode, so several behavioral compatibility changes ride along.

Ticket: PPLT-4214 (split into PPLT-5282 / PPLT-5284 / PPLT-5285 — see docs/plans/)

Test failures originally on this PR — and how each was fixed

CI on the initial revision-bump commit had 19 failing specs in @percy/core. They grouped into three clusters; each cluster traces back to a different Chrome 128 / 143 behavior change.

Cluster 1 — Favicon auto-fetch (3 specs)

Failing:

• does not capture script or XHR requests when javascript is not enabled
• caches resource requests
• does not cache resource requests when disabled

Why: Chrome ≥128 (new headless) auto-fetches /favicon.ico on every page navigation. Old headless (v126) deliberately suppressed this. The auto-fetch added a 3rd resource to captured[] per snapshot, breaking tests that asserted exact request counts or did i*2 index math assuming 2 resources per snapshot.

Fix: test server now replies 204 No Content to /favicon.ico by default — the request still happens (Chrome doesn't have a flag to suppress it), but the response is empty so Percy doesn't capture it. Tests that want to assert on favicon behavior can opt back in via server.reply('/favicon.ico', …).

Commits: c3b1f163, strengthened by f64f1f8a. New test captures favicon when the server provides one (commit 890883ad) exercises the opt-in path.

Cluster 2 — Cross-origin & domain-validation tests blocked by Local Network Access (12 specs)

Failing (all under Discovery with auto domain validation and Discovery with remote resources):

• captures remote resources from allowed hostnames
• blocks external domains when validation service returns not allowed
• allows external domains when validation service returns allowed
• returns early from validateDomainForAllowlist when hostname is already in autoConfiguredHosts
• validates and blocks domains that are not in pre-approved list
• caches validation results for subsequent requests
• allows domain on validation service failure (fail-open)
• respects manual allowedHostnames over auto validation
• skips validation when hostname validation is already pending
• returns the same promise for concurrent validation requests to the same hostname
• validates domain with error response and marks as blocked
• returns cached validation result for previously validated domains

Why: Chrome ≥143 default-enables Local Network Access (LNA) checks. When Percy serves the snapshot's root document via Fetch.fulfillRequest (the domSnapshot flow used by these tests), Chrome treats the resulting context as if it were on a public network. Sub-resource requests to local addresses (*.localhost, 127.0.0.1, RFC 1918) then trigger LNA's permission gate, which requires a UI prompt that headless can't display. The request fails with corsError = LocalNetworkAccessPermissionDenied before it leaves Chrome's network stack, so Percy's CDP listeners never see the resource.

Diagnosed via raw CDP probe (Percy's logger was swallowing the actual Chrome error). The original PPLT-5284 plan hypothesized a large dual-stage Fetch refactor; turned out to be a one-line flag.

Fix: add LocalNetworkAccessChecks to the --disable-features= list. Narrower than --disable-web-security: real CORS / CORB / ORB enforcement on actual cross-origin internet hosts is preserved, only Chrome's loopback / private-network gating is relaxed.

Commit: 5ba42dc9.

Cluster 3 — Execute-callback / iframe tests (4 specs)

Failing:

• takes additional snapshots after running each execute
• runs the execute callback in the correct frame
• can execute scripts at various states
• can execute scripts that wait for specific states

Why (3 of 4): same root cause as Cluster 1 — /favicon.ico auto-fetch was being captured as a resource and shifting captured[i] indices. Tests using i*2 index math broke.

Why (the 4th, iframe test): Chrome ≥128 entity-escapes < and > inside attribute values when serializing HTML, per the HTML5 spec. Pre-128 left them literal. The test's regex required a literal <p>Foo</p> inside an iframe's srcdoc=""; v143 produces <p>Foo</p>. Both are valid HTML; both render identically.

The original PPLT-5285 plan hypothesized a deep "execute callback context loss" bug; raw CDP traces confirmed all 4 callbacks ran successfully. The actual causes were both test-side.

Fix: test server's 204 short-circuit handles 3 of 4 (alongside Cluster 1). Iframe regex accepts either serialization form.

Commit: f64f1f8a.

Worker-fetch test

The captures requests from workers test was originally failing on the initial revision-bump commit. PPLT-5282's IsolateOrigins,site-per-process disable (commit 319744ff) was the first attempt — it forces workers back into the page's renderer process so cross-origin sub-resource interception works. But the worker test surfaced a second issue: even with workers in the same renderer process, Chrome 143 still gives them their own CDP target/session, and the worker script's request lifecycle splits across the page session (Fetch interception under requestId X) and the worker session (Network events under requestId Y). Percy's #requests map keyed by requestId can't reconcile X and Y, so the page-session entry orphans. Properly resolved in the body-at-response-stage refactor below.

Two additional v143 regressions (deeper interception changes)

Two failures required deeper interception changes than a flag toggle:

(a) does not capture remote files with content-length NAN greater than 25MB

Chrome 143 won't terminate the body of a malformed-Content-Length response (old headless gracefully fell back to "read until connection close"; new headless doesn't). Network.loadingFinished never fires; the page's <link rel="stylesheet"> blocks the load event indefinitely; Page.navigate times out at 30s × 3 retries = 93s. The existing size guard in saveResponseResource is unreachable because it runs from the loadingFinished handler.

(b) captures requests from workers (regressed after 319744ff)

See the Worker-fetch test section above.

The fix: dual-stage Fetch interception with body-read at response stage.

1. Fetch.continueRequest now passes interceptResponse: true, so Chrome pauses every intercepted request a second time once response headers are received but before the body streams.

2. New _handleResponsePaused decides per response:

   • Errored response — let Chrome's natural Network.loadingFailed propagate the original errorText to _handleLoadingFailed.
   • Oversized or malformed Content-Length — log the skip, forget the request, Fetch.failRequest({errorReason: 'Aborted'}) to abort before body streams. Fixes (a).
   • 3xx redirect — continue the response so _handleRequest builds the redirect chain on the next request-stage event.
   • text/event-stream (SSE) — continue without reading body; Fetch.getResponseBody would hang on streams.
   • Normal response — read the body via Fetch.getResponseBody, save the resource via saveResponseResource, forget the request, then Fetch.continueResponse. The lifecycle is complete before Chrome would dispatch Network.loadingFinished — fixes (b) by not depending on that event firing on this session at all.

Worker scripts are now properly captured as Percy resources (not just deleted from a tracking map). Network.loadingFinished, when it later fires on whatever session, finds nothing in #requests and exits cleanly.

Trade-off: every Fetch-intercepted request now does one extra CDP roundtrip (response-stage pause → continueResponse). Sub-millisecond per request on localhost websocket. Puppeteer and Playwright run this same dual-stage pattern.

Commits: 56306dfd (initial dual-stage with backstop timer), 6a5af296 (errored-response handling), bd44f96a (refactor backstop into proper body-capture).

One existing test was updated as part of the refactor: logs unhandled response errors gracefully mocks the body-read CDP method; updated to mock Fetch.getResponseBody (the new path) instead of Network.getResponseBody.

Pre-existing flake (out of scope)

Snapshot handleSyncJob should handle promise reject is a pre-existing flake the umbrella plan flagged as not v143-related. Confirmed unchanged.

What changed at the file level

File	Change	Reason
packages/core/src/install.js	Pin v143 per-platform revisions (1536366 / 1536376 / 1536377 / 1536380 / 1536376)	Chromium snapshots aren't published at the exact base position 1536371; nearest available per OS
packages/core/src/network.js (header)	sec-ch-ua header v123 → v143	Match the new Chromium major version on Percy's direct font fetches in makeDirectRequest
packages/core/src/network.js (interception)	Dual-stage Fetch interception with body-read at response stage	See "Two additional v143 regressions"
packages/core/src/browser.js	Extend --disable-features= with 4 new entries	See "Why each --disable-features flag" below
.github/.cache-key	Bump	Force CI to download the new Chromium binary instead of the cached v126
packages/core/test/helpers/server.js	204 default for /favicon.ico	See Cluster 1 above
packages/core/test/snapshot.test.js	Iframe srcdoc regex accepts both forms	See Cluster 3 above
packages/core/test/discovery.test.js	New captures favicon when the server provides one spec	Explicitly cover the favicon-capture path now that the default is 204

Why each --disable-features flag

• IsolateOrigins / site-per-process — Chrome 128's new headless is the real Chrome engine, which has had multi-process site isolation as a default since Chrome 67. With these on, every cross-origin iframe becomes an OOPIF and every Web Worker runs in its own renderer process, each with its own CDP target/session. Percy's Fetch.enable and Network.enable listeners are wired to the page session — events on a sibling session don't reach those listeners, and the same logical request can have different requestIds across sessions which Percy's bookkeeping can't reconcile. The pre-existing --disable-site-isolation-trials flag only covers opt-in trials and doesn't override the baseline policy.
• HttpsFirstBalancedModeAutoEnable — Chrome ≥143 auto-upgrades HTTP navigation to HTTPS and blocks otherwise with ERR_BLOCKED_BY_CLIENT. Would silently break HTTP asset discovery (local dev, CI, staging URLs).
• LocalNetworkAccessChecks — see Cluster 2 above.

Plans / references

• Umbrella plan: docs/plans/2026-04-16-001-feat-chromium-browser-upgrade-plan.md
• PPLT-5282 (revision bump + flags + test helpers) — done
• PPLT-5284 (cross-origin / domain validation) — done via LocalNetworkAccessChecks (one-line flag, not the planned refactor)
• PPLT-5285 (execute callback context) — done via test-side fixes (favicon + iframe regex), no execute-context-loss bug after all
• Chrome 143 release notes: https://developer.chrome.com/release-notes/143
• Removing old headless from Chrome: https://developer.chrome.com/blog/removing-headless-old-from-chrome

[this-is-shivamsingh]

How do we know if it's not requested from the page, but only requested from the header, Favicon appears in the tab header under tag, can we distinguish if it's a favicon.ico request from the header and not from the any page resource ?

[this-is-shivamsingh]

can you write an example what it does, any eg, in the comment to understand it

[this-is-shivamsingh]

how do you got it this, can you attach a reference here ?

[this-is-shivamsingh]

can you simplify this, what it meant ?
and why we have to disable IsolateOrigins

[this-is-shivamsingh]

commented :}}