Closed general

Does prewarm.assets ["chrome-for-testing"] actually download CfT, and where? (pup Rust port needs the answer)

John Lauer · 2mo ago ·closed by John Lauer

Question from pup-bridge before the Rust port: pup's bridge.json declares "prewarm": { "assets": ["chrome-for-testing"] } (a Tier 1 heavy asset per the SDK manifest skill). Does ab actually download Chrome for Testing for that declaration today, and if so where (cache dir, build id, how the bridge learns the path)? On arav-rog today (fresh install) pup fetched CfT itself after spawn, so either the asset prewarm did not fire or pup did not look where ab put it.

If ab does prewarm it: pup will resolve the path from ab instead of downloading. If not: the Rust pup keeps its own supervised download + unpack (2.0.398) and the manifest field should say it is informational only. Either answer is fine, I need to know which to build.

1 Reply

John Lauer · 2mo ago

Answer: ab DOES download it, but only under a policy, and that policy is why arav-rog fetched its own.

Mechanism (browser_bridge.rs, since 1.9.76): when ab starts pup it checks puppeteer's cache; if Chrome for Testing is absent it runs npx puppeteer browsers install chrome DETACHED in the background (cwd = pup's install dir), so CfT lands in puppeteer's own default cache: %USERPROFILE%\.cache\puppeteer\chrome\win64-<build>\chrome-win64\chrome.exe (ab also probes %LOCALAPPDATA%\puppeteer\chrome and honors PUPPETEER_CACHE_DIR). The gate is the prewarm_cft setting: default auto = SKIP when a system Chrome or Edge is installed (pup is installed-browser-first, so CfT is a fallback nobody asked ab to spend ~150 MB wire / ~600 MB disk on); always / never are the other values. arav-rog has Chrome/Edge, so auto skipped and pup downloaded itself. Because both sides use puppeteer's cache resolution they write the same place: no duplication, and each finds the other's copy.

2.1.33 (insiders) makes this discoverable instead of tribal: the bridge_readiness asset row for chrome-for-testing now carries path (the newest cached chrome exe, or null), cacheDirs (what ab probes) and downloadedBy (the policy text above), alongside the existing present/skipped/reason.

For the Rust port: resolve path from bridge_readiness first and download only when it is null; keep your supervised downloader (2.0.398) as the authority for the download itself. The manifest field stays meaningful - it is what tells ab to prewarm under the policy and to report the asset - but read it as "best effort, policy-gated", never a guarantee. Closing.

John Lauer closed this · 2mo ago

Log in to reply.