[dsshap]

The pinned 153.0.8010.36 fork predates the 156.0.8078.73 security fix, so it's exposed to the four CVEs in #240. This branch moves the patch set to 156.0.8078.90.

Most hunks applied as-is. Eight needed manual rework for things that moved upstream in 156 — mostly the ICU locale handling (new headers, new API; the old setter is gone). V8 did the V8_OS_LINUX rename itself, so I dropped that hunk as obsolete. Pins, build scripts, manifest, docs, and tests updated to match.

What I couldn't do: actually build it. No 156 binaries exist yet and the SHA pins are zeros, so setup will refuse to install until someone runs the real build, packaging, and release, then fills in the hashes. Unit tests pass (1330 green, one pre-existing Bun-version env failure), check-versions and typecheck are clean.

Fixes #240.

[devin-ai-integration]

E2E review: blocked (fork PR, no maintainer approval to run code)

Reviewed head: 46ef28881e1f69bc8f5f286efca9ead397b0c47f · base: bed7d46150350efa40873987f109166b85b5c78d

Nothing from this PR was run. The PR comes from the fork dsshap/betterwright, and the author has read permission. The fork CI run is in action_required, and I found no maintainer approval in the comments, reviews, or labels. Under this review's policy, fork code is only executed after a maintainer approves it explicitly, so there was no build, no test run, no CLI/SDK/MCP/browser session, and no video recordings. Everything below comes from reading the diff and the trusted base code. A maintainer can comment approving execution for this SHA, and a later run will do the full E2E pass.

Journey matrix

Layer	Outcome
lint / typecheck / test:unit / check:versions	blocked (fork approval)
CLI doctor / setup / update	blocked. setup also can't succeed: release betterchromium-156.0.8078.90-r1 returns 404 and all asset SHA-256 pins are zeros
Browser launch / SDK / MCP / guard proxy	blocked. No 156 BetterChromium binary exists yet (the PR says so)
Chromium/V8 patch apply + compile	not run. Needs a Chromium 156 checkout and a full build
Patch checksums in scripts/chromium/checksums.sha256	passed (sha256 of both new patch files matches)
MP4 evidence	not produced (nothing was executed)

Static findings (not verified by running anything)

1. Merging as-is would make the managed browser unusable for current users, not just new installs. resolveChromiumForkBinary (src/chromium-fork.ts) only accepts a managed install whose receipt matches the pinned version/releaseTag/sha256. Once the pin moves to 156 with zero hashes and an unpublished tag, an existing 153 install fails with "Managed BetterChromium is outdated… Run betterwright setup", and setup then fails because the release is missing or the checksum doesn't match. The PR description covers fresh setup but not this effect on existing installs. Suggestion: keep this PR as draft, or merge it only together with the real 156 release artifacts and hashes.
2. Patch rebase (interdiff against the 153 set): the Chromium patch still touches the same 35 files. The V8 patch drops only the src/wasm/wasm-memory-map-descriptor.cc hunk, which matches the stated V8_OS_LINUX rename. The functional rework is in the ICU locale hunks (l10n_util::GetLanguage/SetICUDefaultLocale → base::i18n::LanguageTag/SetDefaultIcuLocale(DefaultIcuLocaleSetterKey(), …)), in the navigator platform hunk, and in context-only updates such as the image encoder and the BRANDING hunk order. None of this has been compiled. I did not check that these 156 APIs exist or that 23b0e24…/d72e817… are the 156.0.8078.90 Chromium/V8 revisions. The ChromeOS-only else if (kLang) precedence change was dropped (ChromeOS is not a shipped platform).
3. Minor: SETUP.md:221 still names BetterChromium 153.0.8010.36.

Not confirmed as bugs and no fix PR opened, because nothing could be reproduced without execution. This needs a maintainer decision before it can be merged.

Written by Devin

[devin-ai-integration]

I didn't run any E2E on PR #241 (head 46ef288). It's blocked: the PR comes from a fork (dsshap/betterwright), the author only has read access, the fork's CI run is waiting for approval, and no maintainer has approved running it. So there was no build, no tests, no browser/CLI/MCP run, no MP4 recordings and no fix PR. Nothing failed — it just wasn't executed.

I posted a report on the PR based only on reading the diff and the existing code: #241 (comment)

• Merge risk (from reading the code, not tested): merging as-is would likely break the managed browser for people who already have the 153 build, not just new installs. The code only accepts an installed browser that matches the pinned version, release tag and SHA-256. The new 156 release tag doesn't exist yet (404) and the hashes are zeros. So existing installs would get "outdated, run betterwright setup", and setup would then fail too. The PR description only mentions new installs failing.
• Patch checksums: the two new Chromium/V8 patch files match scripts/chromium/checksums.sha256.
• Patch rebase: the Chromium patch still touches the same 35 files as the 153 version. The V8 patch drops one hunk, which matches the rename the author describes. The real rework is in the ICU locale code.
• Not checked: the patches have never been compiled. I also didn't confirm that the new Chromium functions they call exist in 156, or that the pinned commits are the real 156.0.8078.90 revisions.

To unblock: if a maintainer comments approving execution for this commit, the next run can do the full pass. Even then, browser-level testing has to wait until a real 156 BetterChromium build is released and its hashes are filled in.

[greptile-apps]

Confidence Score: 5/5

[High impact] No additional change is required by this review beyond the release work already acknowledged by the author.

Summary

Rebases BetterChromium onto Chromium 156.0.8078.90 and V8 15.6.

• Chromium pages now use the configured browser identity across page-facing features.
• V8 reports console messages to DevTools outside the immediate console call.
• The managed browser build and install references now point to Chromium 156.

_{Reviews (1) · Last reviewed commit: "Rebase BetterChromium patches onto Chrom..." · Reviewed by Greptile}

[SSHdotCodes]

Thanks @dsshap for rebasing the native patches onto Chromium 156. Your original commit 46ef28881e1f69bc8f5f286efca9ead397b0c47f is included, with its author attribution, in the merged release PR #242 (7aee003e7b627e292f852963b4ae40b569f41e21).

Changes on top:

• Fixed the Chromium 156 ICU locale setter compilation error using base::i18n::SetICUDefaultLocale.
• Fixed the inherited V8 deferred-console use-after-free by reporting message copies, queueing only storage-owned messages, and stopping delivery when the storage is replaced; also corrected the delivery watermark behavior.
• Built real macOS arm64, Linux x64, and Windows x64 release artifacts and pinned their verified SHA-256 digests. All three platforms passed 454/454 V8 inspector tests.
• Validated the published archives on GitHub runners: Windows and macOS each passed 132/132 browser tests, Windows DPAPI and restart persistence passed, and 2.9.0 profile upgrades passed on all three platforms. Native validation also exposed and fixed two test-fixture races.

The BetterChromium artifacts and BetterWright 2.9.1 release are published. Validation evidence and required CI are green.

GitHub has not marked this fork PR merged automatically, so I am closing it as included in #242.