Renderer crashes reliably on fingerprint.com and creepjs.org

[ingepanch13011]

Chrome 149

Loading https://fingerprint.com/ kills the renderer process. Playwright's crash event fires and
the tab is unrecoverable. The same page in stock Chrome on the same machine, same network, is fine.

https://creepjs.org/checker crashes the same way, reportedly after it finishes collecting.

The crash is not in the fingerprint layer: it reproduces with no fingerprint option passed at
all, on a bare launchPersistentContext, with no proxy and no capture.

Reproduction

import { launchPersistentContext } from "clearcote";

const context = await launchPersistentContext("./probe", { headless: false });
const page = context.pages()[0] ?? (await context.newPage());
page.on("crash", () => console.log("RENDERER CRASHED"));

await page.goto("https://fingerprint.com/", { waitUntil: "domcontentloaded" });
await new Promise((r) => setTimeout(r, 20000));

await page.evaluate("1+1");   // throws: Target crashed

Reproduces every attempt. creepjs.org/checker needs a longer wait — roughly 35 s — because it
crashes late rather than on load.

[pim97]

Thanks for the precise repro — the detail that it happens with no fingerprint option, on a bare launchPersistentContext, is what made this quick to test.

I cannot reproduce it on the current build. Running your reproduction on 151 (Pro r13):

	fingerprint.com	creepjs.org/checker
Windows	survived, 2 of 2 attempts	survived, 2 of 2 attempts
Linux	survived	survived

Both pages load fully and the renderer stays alive for the whole wait — 25s for fingerprint.com, 40s for creepjs, past the point where you note creepjs crashes after it finishes collecting. No crash event, and evaluate() keeps working. Same conditions as yours: no fingerprint option, no proxy, no capture.

That is not the same as saying it is fixed, and I would rather not claim it is. You filed against 149 and I tested 151, so two things changed at once — 21 Chromium majors and a full rebuild of our patch stack. Two explanations fit what I measured:

1. a 149-era bug that the version bump resolved incidentally, or
2. something environment-dependent — GPU, driver, or memory — in which case it may still be live for you on 151

I can't separate those from here, and the second is worth taking seriously: a renderer crash on a fingerprinting page is very often GPU-process related, and my two test hosts (a GPU-less Linux VM, and one Windows machine with a discrete NVIDIA GPU) cover that axis poorly.

Four things from you would settle it:

1. Does it still reproduce on the current Pro build (151.0.7922.108-r13)? That alone distinguishes the two explanations.
2. The chrome://gpu summary from the affected machine, plus OS build.
3. Does it survive with --disable-gpu? That separates a GPU-process crash from a renderer one.
4. Any crash dump in <user-data-dir>/Crashpad/reports — even the file itself is useful.

One thing on our side worth mentioning rather than sitting on: during unrelated testing on 151 we twice saw a browser die with a target-closed error — once after pointer input, once on a page that never finished loading — roughly two runs in a dozen. That is intermittent rather than your every-attempt reproduction, so it may well be unrelated, but it does suggest something can still take the browser down on 151. We are chasing it separately and will link the two if they turn out to share a cause.

Leaving this open.