TPAC 2026: what's on the W3C WebExtensions agenda in Dublin
The W3C WebExtensions groups meet at TPAC 2026 in Dublin, Oct 26–30. The agenda: deferred permissions, a sidebar API, WebMCP. What to do before it.

From October 26 to 30, the W3C's WebExtensions Working Group and Community Group meet jointly at TPAC 2026 in Dublin. It's the first TPAC since the Working Group was chartered, and the agenda is now public: permissions on update, a sidebar API, feature detection, WebMCP and a pile of cross-browser inconsistencies.
If you ship an extension, these sessions shape defaults you'll build against. For scale, our catalog counts 341,931 Manifest V3 listings on the Chrome Web Store, Firefox Add-ons and Edge Add-ons, with ~3.83 billion combined store-reported users. More on what that number does and doesn't mean below.
Registration ran until October 16, and W3C strongly discourages signing up on site. If you aren't registered, the useful part is still open: the threads are public, and the Community Group has one more call before Dublin.
What's confirmed
- Format: in person or online, per the W3C event page. On August 31, W3C made it a joint WG/CG meeting so Community Group participants could register: Monday afternoon, Tuesday morning, most of Thursday and Friday
- The Working Group: chartered from May 12, 2026 to May 12, 2028, chaired by Timothy Hatcher (Apple) and Simeon Vincent, with its first meeting on June 25
Don't over-read the upgrade. A Working Group publishes formal W3C specifications, but this one's charter targets Candidate Recommendation Snapshots and says the group "does not intend to advance their documents to Recommendation."
The TPAC 2026 agenda, day by day
Per the group's coordination wiki, last edited October 15:
- Monday 26: a ~15-minute state of extensions from each browser vendor, then spec progress
- Tuesday 27, 08:30: deferred permissions (45 minutes), a unified sidebar API, and a proposed
browser.runtime.supports(), modelled onCSS.supports(), to check whether an API is supported - Wednesday 28, 14:00 (tentative): a breakout on bringing WebMCP, the draft spec that lets sites offer tools to AI agents, into extensions
- Thursday 29: cross-browser inconsistencies (validation, menus, alarms), to become call-outs in the spec text; bug triage; types and constants in
browser.* - Friday 30: more bug triage, then a wrap-up of decisions and action items
Eight Thursday and Friday slots are still open "for topics that come up during the week."
The session that touches your manifest
Adding a warning-triggering permission to an installed extension has two routes today, as a comparison thread lays out. Put it in permissions and every existing user sees the warning on update, or put it in optional_permissions and request it at runtime, forever. Three proposals compete to fix that:
- #798: a
permissions_behaviorkey whose"defer"setting treats permissions added in an update like optional ones - #883:
initial_permissionsandinitial_host_permissions, the broader option, open since October 2025 - #1109:
deferrable_permissionsanddeferrable_host_permissions, opened October 8 by a 1Password engineer, granted up front on new installs and optional on existing ones until you move them intopermissions
Tuesday's stated goal is to go through "the 1Password proposal in detail" and identify blockers. If you've ever held a permission back because of the update warning, this is your session.
Not on the agenda: the storage cap
Issue #1028, which I covered in June, proposes an approximate 1 GB limit per set() or get() call for extensions with unlimited storage. It has no tpac 2026 label and has been quiet since June 21; on the day it was filed, a group member asked whether hard limits are needed at all. If you declare unlimitedStorage, as 14,386 listings did in our June count, it needs an open slot or the October 22 call to come up.
How fast talk becomes code
The recent benchmark is async listener registration. The Chrome-sponsored proposal was created April 27; its manifest key merged into Chromium on August 20 and reached Chrome 154 stable on September 22. That was only the parsing half, behind a flag that's off by default, with runtime behavior left to follow-up changes (our retrospective has details). Budget months, not weeks, between a TPAC decision and something your users can run.
What the 341,931 counts
It counts listings whose latest snapshot declares Manifest V3 on those three stores, so an extension on two stores counts twice. The ~3.83 billion sums each listing's store-reported users; it isn't unique people. It includes 21,649 listings (~231M users) already unavailable in their store at our last scan.
Read it as scale, not as a count of who any session affects. The catalog can't see which extensions request permissions after install, and the count leaves out Safari, which we don't index, and Firefox add-ons still on Manifest V2. We once misdescribed a number like this in our Chrome 154 post and corrected it, so I'd rather spell it out.
What to do before October 26
- Read the thread behind your session: #1032, #883 and #1109 for permissions on update; #1028 for large storage writes
- Comment now, in public: to get a topic onto the October 22 Community Group call, nominate it in #1113 before suggestions close, about 48 hours ahead; taking part starts with joining the Community Group, which needs a W3C account
- Follow the week after: minutes land in the repo's
_minutesfolder, and TPAC topics carry thetpac 2026label
When outcomes turn into manifest edits, my free Manifest V3 generator builds a cross-browser manifest with live store-policy validation, no sign-up. The @extenshi/cli scanner runs a pre-publish security scan on your own build: 3 scans and 10 reads free with a free account, one-time, then prepaid credit packs.
Standards week looks ceremonial from outside. It's where future defaults get argued, and the arguing is public.
See where your extension stands in the catalog → — its manifest version and store status on Chrome, Firefox and Edge.
Sources
- W3C TPAC 2026 event page — dates, in person or online
- TPAC 2026 registration — open until October 16, 2026
- WebExtensions Working Group charter — dates, chairs, Candidate Recommendation target
- 2026 TPAC coordination wiki — agenda as of October 15, 2026
- Integrating WebMCP into WebExtensions — breakout session page
- w3c/webextensions#1032 — the permissions-on-update proposals compared
- Chromium CL 8272039 — manifest key, parsing only, flag off by default
- Chrome 154 milestone schedule — stable September 22, 2026
Catalog numbers come from Extenshi's scans of Manifest V3 listings on the Chrome Web Store, Firefox Add-ons and Edge Add-ons, as of October 12, 2026; counts shift as we re-scan. Agenda details are as of October 16, 2026 and may change. The proposals cited are open discussions, not shipped changes, and we don't independently verify upstream claims. If you think something here is inaccurate, tell us at [email protected].
Related Articles

unlimitedStorage explained: the extension permission with no ceiling — and the W3C plan to add one
The unlimitedStorage permission lets extensions hoard data on your disk with no cap. ~687M users are exposed — and W3C is debating a limit on July 2, 2026.
Chrome 154 landed MV3's lost-event fix — for up to 276,820 Chrome extensions that can't use it yet
Chrome 154 shipped the async_listener_registration manifest key for MV3 service workers. Here's what landed, who it covers, and why you shouldn't switch yet.

We counted what Chrome's Manifest V2 sunset actually removed — and it wasn't the ad blockers
Everyone said Chrome's Manifest V2 deadline would kill ad blockers. Here's what the sunset actually stranded — and why Firefox is now the MV2 refuge.
Host permissions explained: what 'read and change all your data on all websites' really means
Browser extension host permissions let extensions read and change every website you visit. Here's what that warning actually means and when to be concerned.