Chrome 151 shipped to stable on July 28, and while most browser release notes are safe to skim, this one has a deadline buried in the changelog that extension developers and enterprise IT teams should not skip past: Chrome 151 removes the AllowLegacyMV2Extensions enterprise policy flag entirely, deleting the last remaining code path that let organizations keep Manifest V2 extensions running past their deprecation. Manifest V2 extensions already stopped running for ordinary users when Chrome 138 shipped; 151 removes the leftover enterprise-override machinery, which means any organization that's been using that flag as a stopgap now has zero remaining path to keep MV2 extensions alive on Chrome.
Why the MV2 removal deadline matters more than it looks
If your organization manages Chrome via enterprise policy and has been relying on AllowLegacyMV2Extensions to keep a legacy internal extension, an older ad-blocker, or a vendor tool running past the general MV2 sunset, that extension stops working the moment your fleet updates to Chrome 151 — not gradually, not with a grace period, immediately. This is worth flagging to IT and security teams specifically, because "we'll deal with the extension migration eventually" is a sentence that's been technically true for over a year since Chrome 138 first deprecated MV2 for regular users; Chrome 151 is the point where "eventually" runs out for enterprise-managed fleets too. Any team still running MV2-dependent tooling needs Manifest V3-compatible replacements identified and tested before this update reaches their managed devices, not after users start reporting a broken extension.
Why Chrome's release notes deserve a designated internal reviewer
Given how much variety a single Chrome release can contain — a hard enterprise policy deadline, several new web platform primitives, and incremental API refinements all landing in the same changelog — organizations of any meaningful size building on the web platform benefit from assigning a specific person or small rotating group the explicit responsibility of reviewing each Chrome release's notes in full, rather than relying on individual engineers to notice relevant changes incidentally. This is a lightweight process to establish and a common gap: most engineering teams have someone who tracks their primary framework's release notes closely, but browser release notes often fall into a gap between frontend engineering and IT/security ownership, with each side assuming the other is watching. Chrome 151 is a useful, concrete example to cite internally if you're making the case for assigning this ownership explicitly, since it demonstrates a scenario where missing the browser release notes has a real, dated consequence — a broken extension on a specific update — rather than a purely theoretical risk.
The four platform features actually worth adopting
Beyond the MV2 cleanup, Chrome 151 ships a handful of genuinely useful additions to the web platform that got less attention in the release notes than the extension policy change, but matter more for day-to-day frontend development.
Declarative Shadow DOM slot assignment lets web components use manual slot assignment without imperative JavaScript — previously, assigning content to specific named slots inside a shadow DOM tree required running JavaScript after the DOM parsed, which meant server-rendered or streamed HTML using shadow DOM components couldn't fully declare their slot structure up front. This closes a real gap for teams building web components with server-side rendering or static generation, since slot assignment can now be fully expressed in markup rather than requiring a client-side JavaScript pass to finish the job.
Soft Navigations and interaction performance metrics extend Chrome's performance measurement APIs to track interaction-driven latency and route changes specifically within single-page applications — a category of navigation that traditional performance APIs, built around full page loads, have historically measured poorly. For any team running Core Web Vitals monitoring on a React, Vue, or similar SPA-style application, this is a meaningful upgrade to measurement accuracy, since client-side route transitions have previously been a blind spot in standard performance tooling built around the traditional page-load model.
The <usermedia> capability element provides a new declarative, user-activated control for camera and microphone streams. Rather than requiring JavaScript to request getUserMedia() permissions and manually build UI around the resulting stream, this gives developers a native HTML element for camera and microphone capability requests — reducing both the code required and the number of ways a poorly implemented permission flow can create a confusing or untrustworthy-looking prompt for users.
Animation Event improvements add a read-only animation attribute to the AnimationEvent and TransitionEvent interfaces, returning the associated Animation object that triggered the event. This is a small but genuinely useful addition for anyone building complex, JavaScript-driven animation sequences, since it removes a common workaround where developers had to manually track which Animation object corresponded to which fired event.
What to actually do with this release
-
Audit your organization's Chrome enterprise policy configuration today if you have any reason to believe AllowLegacyMV2Extensions is set. If it is, identify every extension it's currently propping up, confirm each has a Manifest V3-compatible replacement, and test that replacement before your managed Chrome fleet updates to 151 — this is not a "next quarter" item given the immediacy of the removal.
-
If you maintain browser extensions professionally, confirm your own extensions have been fully migrated to Manifest V3 if you haven't already — any users relying on your MV2 version, even through workarounds, lose that functionality entirely as their browsers update.
-
Evaluate whether Soft Navigations metrics should be added to your existing performance monitoring setup if you run a single-page application. This is a genuine accuracy improvement over previous SPA performance measurement approaches, and it's a low-effort addition if you're already instrumenting Core Web Vitals.
-
Consider the
<usermedia>element for any camera or microphone permission flow you're currently building with manualgetUserMedia()JavaScript, particularly for new features, since the declarative approach reduces implementation surface area and is likely to produce a more consistent, trustworthy permission UI across different sites than each team's custom JavaScript implementation. -
Don't treat browser release notes as routine reading you can skip during busy sprints. This release is a clear example of how a browser update can contain both a hard deadline requiring immediate action (the MV2 policy removal) and genuinely useful new platform capabilities in the same changelog — treating browser updates as background noise risks missing the former even if your team doesn't care about the latter.
What enterprises got wrong about the original MV2 deprecation timeline
It's worth being direct about a mistake many enterprise IT teams made when Chrome 138 first deprecated Manifest V2 for regular users: treating the AllowLegacyMV2Extensions enterprise policy as a durable, long-term solution rather than what Google had explicitly signaled it would be — a temporary bridge for organizations that genuinely needed more migration time. Google's own documentation at the time of the original deprecation was clear that the enterprise override was intended to be time-limited, not a permanent exemption, but it's common for a policy flag that "just works" to get treated informally as solved-and-forgotten rather than tracked as a ticking deadline. Chrome 151's removal of that flag is a predictable consequence of a timeline Google telegraphed clearly, and organizations caught off guard by it are experiencing a planning failure on their own side, not an unreasonably abrupt change from Google. The lesson worth internalizing for the next similar deprecation cycle — and there will be one, since browser vendors phase out legacy capabilities regularly — is to treat any "temporary enterprise override" flag as an active project with an end date from the moment it's enabled, with an owner responsible for tracking the eventual removal, rather than a install-and-forget workaround.
A practical migration checklist for teams still holding MV2 extensions
For any organization discovering through this release that they still have MV2-dependent tooling in production, the migration path generally involves several concrete steps worth laying out explicitly, since "migrate to Manifest V3" is often stated as if it's a single well-defined task rather than a multi-part project. First, inventory every extension currently in use across your organization, including ones installed informally by individual teams rather than through centralized IT deployment — shadow extension usage is common and easy to miss in an initial audit. Second, for each extension, determine whether an official Manifest V3 version already exists from the same vendor or developer, since many popular extensions completed their own migration well before this deadline and the fix may be as simple as updating to a current version. Third, for internally built extensions your own engineering team maintains, budget real engineering time for the migration — Manifest V3's more restrictive background script model (service workers replacing persistent background pages) and its different approach to network request modification (declarativeNetRequest replacing the more flexible but more powerful webRequest blocking API) can require genuine architectural changes, not just a manifest file edit. Fourth, test the migrated or replacement extension across your actual managed Chrome fleet configuration, including any enterprise policies that might interact differently with Manifest V3's permission model, before rolling it out broadly.
The pattern Chrome 151 fits into
Chrome's release cadence in 2026 has increasingly paired platform capability expansion with the deliberate, gradual removal of legacy compatibility shims — Manifest V2 support being the most visible example, but part of a broader pattern of the browser vendor ecosystem tightening security and extensibility models even as it adds new declarative, less-JavaScript-dependent primitives to the platform. For frontend teams, that combination means release notes are worth genuine review each cycle rather than a quick scan for breaking changes, since the browser platform itself is absorbing capabilities that used to require framework-level workarounds or third-party libraries.
If your organization manages Chrome at any scale, the MV2 policy removal is today's actionable item. Everything else in this release is worth a slower read when you have bandwidth — but that one item has a deadline that's already arrived.