Browser process segfaults when a WebGPU canvas is re-created after in-document navigation (macOS, 151.1)

[Cristian-Vogel]

Recreating a WebGPU canvas inside a live document crashes the browser process on macOS —
EXC_BAD_ACCESS (SIGSEGV) at 0x10 on CrBrowserMain, reached through
tauri_runtime_cef::external_message_pump::PumpState::do_work, at a constant PC, moments
after the new canvas first paints. The first WebGPU canvas of a document is always fine;
only re-creation within the same document lifecycle crashes.

Repro (Tauri app on tauri-cef-v3.0.0-alpha.23, SvelteKit frontend, macOS arm64):

1. Page A holds a <canvas> with a configured webgpu context.
2. Client-side navigate to page B — page A unmounts, canvas is garbage.
3. Navigate back — new getContext("webgpu") + configure() on a fresh canvas.
4. Browser process segfaults right after the first frame renders. 100% reproducible.

It is not the CN build: identical crash on the fork binaries (151.1.0+151.1.0-HEAD.3585,
first .ips) and on the stock crates.io/Spotify build (151.1.0+151.3.12, second .ips),

crash-reports.zip
Likely upstream Chromium in the embedded compositor path

Crash reports attached: fork build (…-195501.ips) and stock 151.3.12 (…-202511.ips).

[Cristian-Vogel]

Burned a pile of tokens because I do have a 100% reproducibility on a dangling pointer segfault in CEF and wanted to try and really find it - this is a potential vulnerability.

Used Claude Opus againsy my tauri-cef based project (MODARK) it is shippign in beta - to find out that it is fixed upstream, but I can't reach it from tauri-runtime-cef cos it pins cef = "=151.1.0".

Chromium	CEF	Reproducible Crash
151.0.7922.0	151.1.0-HEAD.3585 (CN fork)	segfault, 100%
151.0.7922.174	151.3.24 (Spotify)	no crash
147.0.7727.118	148.0.0+147.0.10	no crash (shipping)

Both 151 runs used the same MODARK binary — identical sha256, built against
cef 151.1.0 bindings at CEF_API_VERSION=15101. Only the loaded Chromium
differed.