Extenshiextenshi.io/blog
Back to articles
extension-pulsechrome-extensionsfirefoxbrowser-extensions

Extension Pulse, week of October 12: Chrome 157's break list is already written

Chrome 157 beta started October 14 with five extension changes merged. Chrome 156 hits early stable. Plus runtime.onEnabled and a rejected W3C proposal.

Maxim Kosterin
12 min read
A row of hairline ticks with one tick missing, an orange watercolor wash in the gap — an event that never arrives.
A row of hairline ticks with one tick missing, an orange watercolor wash in the gap — an event that never arrives.

Chrome 157 branched on October 12, and beta builds started rolling out on October 14. Normally that's when you'd begin paying attention. Too late — the extension-facing slate was written before the branch. Five changes merged to trunk ahead of it and ship with the 2026-11-03 stable. Three of them fail silently. One starts throwing. One is documentation-only.

Here's the whole menu, with merge dates:

webRequest and DNR lose user-restricted initiators. CL 8497010, merged October 2: navigations initiated by sites the user put under "block all extensions on this site" — including outbound link clicks to allowed sites — go invisible to webRequest listeners and stop matching declarativeNetRequest rules. No error is raised; the events just never arrive. Even permission-less DNR block rules stop applying there, which the commit message spells out. It's privacy-correct — a user who blocked a site gets what they asked for — but if your product promises "we see every navigation" (blockers, parental controls, DLP, annotators), that promise now has a user-shaped hole in it. And it's an arc, not a one-off: M153 did the same to chrome.cookies in September (W35 listed it in that train).

chrome.publicSuffix starts rejecting leading dots. The API W35 flagged gets its first breaking tweak. CL 8464103 merged September 30 — the spec PR landed the same day — implementing the WECG's September 24 decision that a hostname like ".example.com" is invalid input. Chrome 154 through 156 tolerate leading dots; from November 3 they error. If you pass cookie-domain-style values straight through, normalize today — don't wait for the error to teach you.

alarms.clearAll() loses its boolean. CL 8182627, merged October 2 with a compatibility kill-switch, aligns Chrome with the WECG #1055 consensus: Promise<undefined> instead of Promise<boolean>. Firefox 157 already shipped it at stable on September 29, and WebKit merged the same change on October 13 (PR 76286), so Safari goes back to undefined too. The old inconsistency — Chrome always resolved true, Firefox resolved true only if something was cleared — is on its way out. Every if (await browser.alarms.clearAll()) branch is dead code on Firefox today and on Chrome from November 3. clear() was not part of this change, but if you wrote one you probably wrote the other. Our alarms deep dive is the place to re-audit your scheduling logic.

One header disappears on Gaia URLs. CL 8501321, merged October 6: X-Chrome-Manage-Accounts joins X-Chrome-ID-Consistency-Response inside ShouldHideResponseHeader(), so extensions holding host permissions for accounts.google.com can no longer read, modify or inject it via webRequest/DNR — "so extensions cannot trigger Mirror account management UI or actions", per the commit message. Narrow audience (enterprise SSO helpers, account switchers, sign-in automation), silent failure, and the supported path forward is chrome.identity.

MV2 contextMenus types go nodoc. CL 8507256, merged October 2: the browser_action and page_action context types leave the docs but keep validating — a documentation-level end-of-life, no runtime break. The more useful line in the same CL: Chrome now documents that "all" excludes "tab". If you registered contexts: ["all"] expecting tab-strip right-clicks, you never had them. An explicit "tab" context is implemented in Chrome, Firefox and Safari (WECG #326).

That's the shape of M157: absence, not deprecation dialogs. Event streams get holes by design, return values go undefined, headers vanish before you can observe them. Stop treating "no event" as "no navigation", and audit every branch on a value the platform is about to stop giving you.

Chrome 156 is already live — and it's dropping header edits

Before you even get to 157: Chrome 156 entered the Stable channel on October 7 — 156.0.8078.12 on Windows and Mac, .25 on Android and Webview — thirteen days ahead of the official October 20 stable date. iOS followed on October 13; Linux was still on 155 as of October 14. It's the same early-stable pattern Chrome 155 ran (channel move September 23 vs a scheduled October 6), so treat it as the rhythm now: your users get the new behavior about two weeks before the release notes do.

Two extension-relevant behaviors are rolling out as you read this:

  • DNR modifyHeaders enforcement (CL 8405278, merged September 15): modifications to hidden/sensitive response headers are now silently dropped — parity with webRequest. Header editors, privacy tools that strip tracking headers: this is live for early-stable users. Test against Stable now, not October 20. If your team is still getting fluent in the DNR rule model, our block/rewrite walkthrough has your back.
  • Guest-webview worker isolation (CL 8422022, merged September 18): <webview> guest Service/Shared Worker requests stop leaking into unrelated extensions' webRequest/DNR listeners.

The stable cut was October 13, and the point-release train started the next day: 156.0.8078.35/.36 reached Windows and Mac on October 14.

runtime.onEnabled — the lifecycle gap Chrome quietly closed

The good-news item. Chrome 155 — full stable rollout complete October 6 — carries runtime.onEnabled, a new lifecycle event that fires when your extension goes from disabled to enabled while the browser is running. The implementation commit landed September 2, before the M155 branch point.

Until now there was no clean hook for "the user turned me back on". onInstalled covers installs and updates, onStartup covers browser launch, and management.onEnabled observes other extensions — not yourself. Companion tools that re-handshake with a native host, license checks that must re-run, sync pipelines that need to re-initialize: they can now hear re-enablement directly, whether it came from chrome://extensions, sync/policy, or management.setEnabled() (the enabling semantics are discussed in WECG #353).

Two caveats. It's Chrome-only — #353 carries supportive labels from all three vendors, but Firefox and Safari haven't implemented it, so guard with if (chrome.runtime.onEnabled). And it gets a broader sibling in Chrome 157: runtime.onExtensionLoaded (commit, September 30) fires whenever your extension joins the set of active extensions — install, update, re-enable, reload, browser startup. A request to rename it runtime.onLoaded was turned down at the October 8 WECG meeting: Oliver Dunk preferred keeping the current name and Rob Wu agreed. So don't code against onLoaded — the name that ships is onExtensionLoaded.

Private DOM classes: all three vendors said no

The proposal to give extensions private CSS classes and attributes — usable as selectors from injected stylesheets, invisible to page scripts — was triaged at the October 8 WECG meeting and closed the same day with opposed: chrome, opposed: safari, opposed: firefox. Rob Wu's closing line: "Too much complexity with unclear gains."

The pitch (#1106, filed October 3) aimed at the ugliest corner of the ecosystem: stylers and content blockers annotate elements with randomized classes, and those markers leak extension presence to the page — basic adblock detection and fingerprinting — plus sites can revert the marking with a MutationObserver. Private markers would have structurally weakened both tricks.

The minutes show how the vendors reasoned. Apple's Timothy Hatcher: getComputedStyle would need to lie to the page — "We do that for visited links, but it's really complicated once you start going down that path" — and any revival needs CSS Working Group coordination, possibly at TPAC. Back in the issue thread, Rob Wu added that even a perfect implementation "would not fulfill your expectations about privacy", because pages can infer hidden state through computed styles anyway. The proposer narrowed the ask to private attributes only; discussion ran through October 9 without changing the outcome.

So the detection arms race stays exactly where it was: randomized markers keep leaking, sites keep sniffing. Unless TPAC 2026 (October 26–30, Dublin) produces a CSS-WG-coordinated revival, stop watching #1106.

The tabs permission you can now drop

Small one, real privacy payoff. WECG #1027 closed October 9 after Oliver Dunk confirmed Chrome fixed the bug where an extension couldn't read url, title and favIconUrl of tabs hosting its own pages without the tabs permission. The fix (CL 8253459) actually shipped back in Chrome 154, so this pattern now works across Chrome, Firefox, Safari and Orion — a complete four-browser implemented set:

const [tab] = await browser.tabs.query({ url: browser.runtime.getURL("inbox.html") });

If you ever requested tabs — with its "Read your browsing history" warning — just to find your own options page or dedupe an internal tab, drop the permission and delete the browser-sniffing workaround branches. Fewer scary prompts for users, less scrutiny at review time.

The rest of the frame

CWS API V1's support window closed October 15. Not from this week's signals: the previous issue (W35) led with Google supporting the Chrome Web Store API V1 only until October 15, 2026, and the V1 reference still carries that warning. If your CI still POSTs to the v1.1 items endpoint, move it to V2 before your next release — don't let a failed upload be how you find out.

Firefox 157 shipped Nova. The September 29 release carries what the Mozilla Add-ons Blog calls the biggest Firefox UI refresh since Proton in 2021. Theme authors: your theme still loads and most color/image properties work, but where they render changes — toolbar and sidebar touch the window edges, vertical tabs are a main layout choice, the default selected-tab shadow is gone — and some theme manifest properties now behave differently or do nothing. The backgrounds_area property (available since Firefox 156) now decides where images go. Firefox 158, out October 13, fixes the theme background on a sidebar that expands on hover; re-check your theme on it, and re-shoot AMO listing screenshots against Nova.

The 2027 calendar has dates. Chromium Dash now lists M165 (branch point 2027-02-22, stable 2027-03-16) and M166 (feature freeze 2027-02-15, branch point 2027-03-08, stable 2027-03-30). Six milestones ship between 2027-01-19 and 2027-03-30 — at a 14-day cadence, deprecation windows expressed in milestones pass faster than they used to. Plan migrations against branch points, not stable dates: whatever is merged by branch is what ships.

What I'd do this week

  1. Install Chrome 157 beta (or Dev/Canary, which already carry these changes) and test the three silent spots: your webRequest/DNR event stream if you promise navigation blocking, publicSuffix inputs with leading dots, and any branch on alarms.clearAll(). A quick grep for clearAll costs ten seconds.
  2. Test Chrome 156 Stable today if you touch response headers via DNR. Early stable is live on Win/Mac/Android, hidden-header modifications are silently dropped, and full rollout completes around October 20.
  3. Wire re-initialization logic to runtime.onEnabled, guarded by a feature check — or to runtime.onExtensionLoaded from Chrome 157 if you want one hook for every way your extension gets loaded. There will be no onLoaded.
  4. Drop the tabs permission if you only needed it to find your own pages, and delete the workaround branches.
  5. Firefox theme authors: load your theme in 157, define sidebar colors explicitly, adopt backgrounds_area if you're image-based, and finalize sidebar-dependent styling on 158, which shipped October 13.
  6. Scan your own build before you ship it. npx @extenshi/cli scan gets you 3 scans + 10 reads free with a free account (one-time); prepaid packs if the M157 audit turns into a habit.

Sources

Methodology

Compiled from 14 Extenshi forecast-pipeline signals dated 2026-10-05 and 2026-10-12. The private-DOM-classes proposal appeared in both scans and is reported at its final (rejected) state. The CWS API V1 reminder comes from the W35 issue, not from this week's window. Every date, merge state and quote was re-checked against the primary source on 2026-10-16.

This issue of Extension Pulse is compiled from Chromium Dash and Chromium Gerrit, W3C WebExtensions Community Group issues and meeting minutes, and Mozilla's add-ons blog and release data. We don't independently verify every upstream claim, and references to specific projects or companies reflect the findings of the cited sources — not accusations of intentional wrongdoing. If something here is off, tell us at [email protected].

Previous issue (W35) → · Browse the catalog →

Related Articles