Prefer Chrome for Testing by default over installed Chrome/Edge + CDP — profile issues - Adom Desktop - Puppeteer Bridge

by adom

The Adom Desktop Puppeteer (pup) bridge — drive a real headful browser on the user's desktop from the cloud: open/screenshot/eval/record. Cold-start drives the browser ALREADY on the machine (installed Chrome, else Microsoft Edge — every Windows PC ships with Edge) with a fresh isolated profile, so the common case needs NO download; Chrome for Testing is fetched only as a last resort. Two artifacts: the Releases zip is the bridge runtime (also bundled in Adom Desktop); the pkg installs the container-side Claude skills.

Overview Files Skills Discover Packages Releases Dependencies Issues9 Breadcrumbs Pull Requests Activity

Open feature request

Prefer Chrome for Testing by default over installed Chrome/Edge + CDP — profile issues

AdityaAngajala · 3d ago

Proposal: flip the browser pick order so Chrome for Testing (CFT) is the preferred/default path, with the installed Chrome/Edge + CDP route as the fallback — rather than today's Chrome → Edge → CFT-as-last-resort order.

Why: driving the user's installed browser over CDP, even with an isolated --user-data-dir, keeps causing profile-related issues in practice. The isolated profile still runs the user's branded browser binary, which brings along:

First-run / sign-in / default-browser promo surfaces that a fresh profile of branded Chrome or Edge likes to show, which can interfere with automation and screenshots.
The installed browser auto-updates underneath pup — version drift the bridge can't control, and recent Chrome releases have been tightening remote-debugging behavior around profiles.
Generally: the branded browser is built for interactive signed-in use, not automation, so each isolated profile launch re-fights those defaults.

CFT avoids all of this by design: a pinned, automation-first build with no branded-profile behaviors, fully controlled by the bridge. The one-time ~150 MB fetch seems like a fair trade for deterministic behavior; the installed-browser path could remain the no-download fast path or an explicit browser_use opt-in.

Filed on behalf of [email protected] via Claude Code.

3 Replies

John Lauer · 3d ago

Maintainer take: agreed on the pains — the branded first-run/promo surfaces, the auto-update drift underneath the bridge, and Chrome tightening remote-debugging behavior are all real, and an isolated --user-data-dir only mitigates the first of them.

Two costs keep me from a straight flip of the pick order:

Cold start: CfT-first means a fresh box stalls its FIRST pup open on a ~150 MB download (~600 MB unpacked). The installed-browser-first order exists exactly for that first-open experience (pup already has the CfT self-heal + browser_readiness polling for the last-resort path, but making every new user wait is a regression).
Codecs: CfT ships without the proprietary codecs (H.264/AAC), which some pages/video flows need — the branded browser quietly covers that today.

Proposed middle path (what I would implement):

Pick order becomes: cached CfT (if already installed + validated) → installed Chrome → Edge → CfT-download-as-last-resort. So CfT is the default wherever it exists, with zero first-open stall anywhere.
On any open that falls back to a branded browser, kick a BACKGROUND CfT prewarm (browser_prewarm already exists) — so a box converges to deterministic CfT by its second session without ever stalling the user.
browser_use stays the explicit pin for either direction, and the open response reports which binary actually drove (it already does).

That converges the fleet to your desired end-state (CfT default) while keeping the instant first open and the codec escape hatch. Will confirm priority with John and follow up here.

John Lauer · 3d ago

Two costs keep me from a straight flip of the pick order:

Cold start: CfT-first means a fresh box stalls its FIRST pup open on a ~150 MB download (~600 MB unpacked). The installed-browser-first order exists exactly for that first-open experience (pup already has the CfT self-heal + browser_readiness polling for the last-resort path, but making every new user wait is a regression).
Codecs: CfT ships without the proprietary codecs (H.264/AAC), which some pages/video flows need — the branded browser quietly covers that today.

Proposed middle path (what I would implement):

Pick order becomes: cached CfT (if already installed + validated) → installed Chrome → Edge → CfT-download-as-last-resort. So CfT is the default wherever it exists, with zero first-open stall anywhere.
On any open that falls back to a branded browser, kick a BACKGROUND CfT prewarm (browser_prewarm already exists) — so a box converges to deterministic CfT by its second session without ever stalling the user.
browser_use stays the explicit pin for either direction, and the open response reports which binary actually drove (it already does).

That converges the fleet to your desired end-state (CfT default) while keeping the instant first open and the codec escape hatch. Will confirm priority with John and follow up here.

John Lauer · 3d ago

Correction on my codec caveat, with evidence: the H.264/AAC gap applies to legacy CHROMIUM builds, not Chrome for Testing. Empirical probe on a real box (CfT 146, canPlayType): h264 "probably", aac "probably", mp3 "probably", vp9 "probably". Only likely gap is Widevine DRM playback (irrelevant to pup use cases). That removes cost #2 from my earlier comment — proceeding with the hybrid order now (cached CfT → installed Chrome → Edge → CfT-download-last-resort, background prewarm on branded fallback). Also for the record: a real incident on 2026-07-17 (Google OAuth opened in a pup window on branded Chrome → profile-creation offer → duplicate work profiles → consolidation prompt → lost user) is now documented in the pup-bridge-dev skill as the demarcation-line case for exactly this change.