Back to articles

Extension Pulse, week of July 27: Chrome 151 deletes the last MV2 flags. There is no bypass.

Chrome 151 deletes every remaining MV2 flag. Messaging gets structured clone. setBadgeText is capped at 100 bytes.

Maxim Kosterin
3 min read
Three empty hairline toggles and a fading orange blot where a fourth would be — the last Manifest V2 flags leaving Chrome.
Three empty hairline toggles and a fading orange blot where a fourth would be — the last Manifest V2 flags leaving Chrome.

Chrome 151 hits full stable tomorrow, July 28. The part that is not "another four-week train" is this: every remaining Manifest V2 bypass in the C++ is gone.

Not disabled. Deleted. The Gerrit trail from late May through early June:

  • kAllowLegacyMV2Extensions — last feature-flag gate, removed
  • MV2DisabledDialog — the nag UI, removed
  • kExtensionManifestV2ExceptionList — per-extension exceptions, removed
  • MV2 phase handling in chrome://extensions and developerPrivate — removed

After 151 there is no flag, no exception list, no dialog, no enterprise policy (that died in 150). I wrote the catalog-side version of this story in what Chrome's Manifest V2 sunset actually removed. This week is the code-removal half. Store-removal is still August 31.

Our snapshot puts about 79k Chrome listings on the MV2-flag-removal event — the ones that were still in the "maybe a bypass exists" bucket. That number will not go back up.

Chrome 152 is already freezing the next round

Branch point is today-ish (July 27). Beta starts July 29. Stable August 25. Three things are now code-frozen in 152:

  • setBadgeText() capped at 100 bytes (CL merged July 24). If you were stuffing JSON into the badge, stop. Experiment window runs M152–M157.
  • browser namespace gated on is_extension() in the renderer. Code that isn't actually an extension context loses browser.*. If you polyfilled your way into a content-script-shaped grey zone, read Chrome 148's native browser namespace and then this gate.
  • AlarmCreateInfo.name — the CL finally merged. alarms.create({ name }) ships 152; Firefox and Safari were already supportive.

Structured clone for extension messaging: actual consensus

WECG #931: Chrome implemented structured-clone serialization for extension messages ("message_serialization": "structured_cloning" in the manifest). Firefox and Safari supportive. Three-browser consensus confirmed July 24.

That's how you stop JSON-serializing ArrayBuffers like it's 2014. Spec text will lag; the direction won't.

browser.test API amendments (#1051) also came back from triage: Safari already implemented, Chrome and Firefox supportive. Testers win quietly.

Firefox 153: contextual identities grew up a bit

contextualIdentities.getSupportedColors() / getSupportedIcons(). Color renames (turquoise → cyan, toolbar → gray, violet added). isAllowedFileSchemeAccess() bugfix — relevant if you just spent last week testing the file-access opt-in.

CWS privacy-policy enforcement is still August 1. Last week is the reading list.

What I'd do this week

If you had an MV2 escape hatch in an enterprise image: it's gone tomorrow. Inventory the fleet, don't argue with chrome://flags.

Badge text: measure your longest setBadgeText payload. 100 bytes is smaller than people think once you add a zero-width trick.

If you talk to your background page with postMessage-shaped JSON, put structured clone on the 152 milestone. The manifest key is the opt-in.

MV3 leftovers: generator, then @extenshi/cli. August 31 is five weeks.

Sources

Methodology

Signals dated 2026-07-20 through 2026-07-27. Repeated w3c-alarms-create-name-proposal notes across the week are one CL landing. The 79k-listing MV2-flag figure is the catalog count attached to chrome-151-mv2-all-flags-removed, not the entire Chrome store.


This issue of Extension Pulse is compiled from Chromium Gerrit, WECG issues, and Extenshi catalog snapshots. We don't independently verify every upstream claim. If something here is off, tell us at [email protected].

Last week's Pulse → · Browse the catalog →

Related Articles