We’re not going to bury this in marketing fluff or “continuous improvement” nonsense. Chrome crashed. It’s our fault.

Here’s the ugly version: our speculative renderer processes started leaking handles into the compositor thread, which in turn forced GPU raster threads to lock a resource already orphaned by a zombie frame. The garbage collector couldn’t reclaim it because of a dangling reference in the shared worker pool, so the watchdog nuked the tab. If you had more than one extension juggling DOM mutation observers at the time, congratulations: you found one of the thousand sharp edges we left in the codebase.

And yes, part of this happened because a programmer came in a little inebriated after an offsite party and checked in a “minor” fix without realizing it created a non-deterministic race condition. We didn’t catch it because we don’t actually have enough test coverage. Why? Because (a) corporate budgeting prefers “features shipped” over “tests written,” (b) we can’t even run full integration tests on Chrome’s codebase without provisioning a farm of servers that costs more per hour than some startups’ entire burn rate, and (c) every time someone proposed fixing this, management reminded us that “users don’t see tests in the release notes.”

We know this isn’t a complete explanation. There are race conditions in the scheduler we still don’t fully understand, extension APIs that trigger undefined behavior in ways no one anticipated, and some memory fences that look more like wet tissue paper. Honestly, we’re apologizing here for not being exact enough and for failing to enumerate every possible case in this post.

So yes: everything got messed up. Yes: it’s our fault. And yes: this announcement is every bit as bad as what HN usually criticizes Google for—just from the opposite direction.

Also, Chrome is set to be retired by March 2028. But you should try Mimi.