Headed Chrome 154 hangs on the first navigation when the collector preload is registered

[vishnuv688]

What happens

With the service active, a headed Chrome 154 session hangs on the first
navigation: browsingContext.navigate with wait: "complete" never returns and
the test dies at the 60 s timeout. The page itself loads and paints normally,
and nothing arrives on the BiDi channel for the whole minute.

Headless is unaffected, which is why CI and the mobile work never saw it. The
documented Chrome matrix for this repo stops at 152.

Cause, by bisection

The collector preload. session.ts registers the built @wdio/devtools-script
bundle, about 213 KB, via browser.scriptAddPreloadScript({ functionDeclaration })
with no browsing-context id. Skipping only that registration and changing
nothing else makes the same navigation complete in 4.66 s.

What that rules out, each by its own run rather than by argument:

Excluded	How
The dashboard window	mode: 'trace' opens none, still hangs
The screencast	filmstrip: false, and live mode starts none
Live vs trace mode	both hang
The published build	the workspace build behaves identically
Occluded-window throttling	the page renders fully while hanging
The network	the site answers in 0.9 s throughout
WebdriverIO or Chrome alone	same spec, same browser, no service: passes in 5.7 s

Reproducing

Any headed Chrome 154 run with the service on. examples/wdio/mocha does it with
its --headless line commented out, as it ships.

BIDI COMMAND browsingContext.navigate {"url":"…/login","wait":"complete"}
   … 60 s of nothing …
Error: Timeout of 60000ms exceeded

What is not yet known

Why a preload of that size stalls the following navigation, and only headed. The
next cut is size against content: register a trivial preload, then progressively
larger ones, which separates a payload limit in the BiDi path from something the
collector does at document start. Until that is answered a fix would be a guess.

Worth noting the same mechanism is shared with the Selenium and Nightwatch
adapters through core/bidi-preload.ts, so this is unlikely to be
service-specific even though that is where it was found.

[vishnuv688]

Bisected: it is payload SIZE, not our collector

Each case is a fresh session that registers one or more preload scripts, then
navigates and times it. Budget 20 s.

registered	headed	headless
nothing	4.49s	3.07s
1 KB of comment	4.12s	2.97s
50 KB of comment	8.81s	2.98s
100 KB of comment	HUNG	2.96s
213 KB of comment	HUNG	3.15s
the collector, 213 KB, global	HUNG	3.24s
the collector, 213 KB, scoped to one context	HUNG	2.98s

A 213 KB block of comment with no behaviour hangs exactly like the collector, so
nothing about what our script does is involved. Scoping does not help.
Headless is flat at ~3 s across every size.

This is a chromedriver / Chrome 154 defect in headed mode, not ours. Anything
registering a preload of this size reproduces it. Worth reporting upstream with
this table.

The cost is per-script and superlinear

Same 200 KB total, split differently:

200 KB registered as	headed
4 x 50 KB	HUNG
10 x 20 KB	13.38s
20 x 10 KB	8.76s

Twenty 10 KB scripts carrying four times the bytes of a single 50 KB script cost
less than it does. So splitting is a real mitigation, and it is not free: 8.76s
against a 3.25s baseline.

What that leaves

• Minifying does not get us there. The bundle is unminified today, and
  minifying saves 12%, to 184 KB. Still deep in the hanging range.
• Chunked registration works but needs the collector rebuilt from string
  parts and evaled, which a page with a strict script-src CSP would block.
  That trades a headed-Chrome hang for losing DOM capture on CSP pages.
• Fetching the collector from the backend, as selenium-devtools-py does,
  removes the payload entirely in live mode, but the JS service starts no
  backend in trace mode, so trace mode would need another answer.
• Shrinking the bundle is the only option with no downside. parse5 is the
  bulk of the 213 KB.

Repro script used for all of the above is in the session scratchpad; it takes a
list of preload payloads and times the first navigation for each.

[vishnuv688]

Composition of the 213 KB payload, since it decides which mitigation is real:

	bytes	share
parse5	148,535	69.5%
preact / htm	47,549	22.2%
the collector itself	17,717	8.3%

Correcting something I wrote above: fetching the collector from the backend is not the safe option I implied. A preload script's body bypasses page CSP, but anything evaluated from a fetched string does not, so that route carries the same script-src exposure as chunking.

Registering less code is the only mitigation with no downside, and #404 tracks it: parse5 serves a serialize-then-reparse round trip the page does not need, and preact builds vnodes the app rebuilds anyway. Removing both lands at roughly 18 KB, which this bisect measures at baseline cost.

[vishnuv688]

Fixed by #404 (dc2ae05). The hang was the preload's size, not its content, and
the bundle was 92% parse5 and preact. With both removed the collector registers
at 10.5 KB, down from 213 KB, which is inside the range the bisect measured at
baseline navigation cost.

Verified headed on Chrome : pnpm demo:wdio:mocha with --headless
removed completes its first navigation normally instead of timing out at 60 s.

packages/script/tests/bundle-size.test.ts now fails the build if the bundle
passes 40 KB or picks up an HTML parser or view library again, so a dependency
added there fails in CI instead of in a user's headed run.

The underlying chromedriver/Chrome behaviour (a single preload above ~50 KB
stalls headed navigation) is still there upstream; we no longer depend on it.