Skip to content

Publish minutes of 2026-01-29 meeting #947

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Rob--W merged 1 commit into from
Feb 12, 2026
Merged

Publish minutes of 2026-01-29 meeting #947

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
174 changes: 174 additions & 0 deletions _minutes/2026-01-29-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,174 @@
# WECG Meetings 2026, Public Notes, Jan 29

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=697bf480,3c0
Call-in details: [WebExtensions CG, 29th January 2026](https://www.w3.org/events/meetings/6a0eda89-558c-408d-b83d-5f03b8853c30/20260129T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #937](https://github.com/w3c/webextensions/issues/937), [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format.

* **Announcements** (2 minutes)
* WECG Face to Face in London
* **Triage** (30 minutes)
* [Issue 939](https://github.com/w3c/webextensions/issues/939): Feature request: Support for WEBP as a possible extensionTypes.ImageFormat option
* [Issue 940](https://github.com/w3c/webextensions/issues/940): Provide a way to distinguish prefetch requests from regular navigations in extension APIs
* [Issue 941](https://github.com/w3c/webextensions/issues/941): Enhancement: management.ExtensionInfo.disabledReason - add value that indicates the extension has been disabled due to incompatibility or even just client-specific reason
* [PR 942](https://github.com/w3c/webextensions/pull/942): Proposal: i18n.getAvailableLanguages()
* [Issue 944](https://github.com/w3c/webextensions/issues/944): Feature request: in-memory storage that persists across extension reload/update
* [Issue 945](https://github.com/w3c/webextensions/issues/945): DNR URL matching and percent encoding
* **Timely issues** (0 minutes)
* **Check-in on existing issues** (25 minutes)
* [PR 932](https://github.com/w3c/webextensions/pull/932): Update runtime.onLoadedReason to match runtime.OnInstalledReason
* [Issue 521](https://github.com/w3c/webextensions/issues/521): sidePanel API: sidePanel.close() and sidePanel.toggle()
* [Issue 422](https://github.com/w3c/webextensions/issues/422): Inconsistency: limits on browser.alarms.create()
* [Issue 463](https://github.com/w3c/webextensions/issues/463): Inconsistency in browser.action: windowId key and enable()/disable() arguments


## Attendees (sign yourself in)

1. Simeon Vincent (unaffiliated)
2. Rob Wu (Mozilla)
3. Oliver Dunk (Google)
4. Dave Vandyke (DuckDuckGo)
5. David Johnson (Apple)
6. Timothy Hatcher (Apple)
7. Ben Greenberg (Aglide)
8. Brandon Lucier (1Password)
9. Maxim Topciu (AdGuard)
10. Carlos Jeurissen (Jeurissen Apps)
11. Benjamin Bruneau (1Password)
12. Anton Bershanskyi (Independent)
13. Giorgio Maine (NoScript, Tor)
14. Mukul Purohit (Microsoft)


## Meeting notes

WECG Face to Face in London

* [simeon] Face-to-face meeting, when?
* [oliver] 7th-9th of April, mentioned last meeting as well. Have yet to create issue and wiki.

[Issue 939](https://github.com/w3c/webextensions/issues/939): Feature request: Support for WEBP as a possible extensionTypes.ImageFormat option

* [simeon] Request for supporting webp JPEG-XL maybe as well?
* [timothy] Supportive of WEBP, and possibly JPEG-XL.
* [david] The report mention that we don't support it.
* [rob] Being able to read/render webp does not necessarily imply the ability to generate webp.
* [timothy] I see that we don't support it with this API. I take the point that it may not be as easy as I initially thought, then.
* [rob] If it's easy to support and there's consensus on supporting it, I'd be supportive.
* [rob] I wonder whether the web platform has received a request for canvas.toDataURL/toBlob support for image/webp generation.
* [oliver] I'd like to follow up internally to check what we can do here.
* [rob] Sounds like we're not immediately opposed, but not strongly supportive either. Neutral all around?
* [oliver] _nods_
* [simeon] That's my impression as well.
* [rob] I'll update labels to indicate that.

[Issue 940](https://github.com/w3c/webextensions/issues/940): Provide a way to distinguish prefetch requests from regular navigations in extension APIs

* [maxim] We recently worked on adding prerender requests in our extension and realized there are also prefetch requests. Currently hard to differentiate between main document and prefetch requests. Would be nice to standardize this behavior and potentially add signals to other APIs such as document lifecycle.
* [rob] Is this just about navigation (main_frame, sub_frame?) or also for subresource requests?
* [maxim] Requests can be differentiated by documentId. We currently see multiple main frame loads taking place for a given tab.
* [rob] And there's no way to see a difference between main frame and prefetch?
* [maxim] There is, but it looks like a hack. Namely, the presence of documentId on the request is the only signal at the moment.
* [rob] What's the proposal?
* [maxim] Add a new document lifecycle prefetch event.
* [rob] Sounds like an initial start. How would an extension determine that a prefetch turned into an actual navigation?
* [maxim] We currently use 2 sources of truth: webrequest and webnavigation.
* [simeon] Naive thought, but would introducing another lifecycle event to convert from prefetch to “activate” (but with a distinct name) be viable?
* [dave] Ran into similar issue, when onHeadersReceived fires, you don't know until the request would be committed. From the extension we tried to detect redirects etc.
* This is that old code extension that I was mentioning, in case it's useful https://github.com/kzar/adblockpluschrome/blob/1affa87724a7334e589c9a7bb197da8d5e5bf878/ext/background.js#L174-L249. I figure the use-cases for knowing if the main-frame request is a pre-render might be similar
* [rob] Likely can't solve this specific use case in this meeting. Would be good to follow up async on this issue to see if we can find a solution that offers a more comprehensive solution to the use case.

[Issue 941](https://github.com/w3c/webextensions/issues/941): Enhancement: management.ExtensionInfo.disabledReason - add value that indicates the extension has been disabled due to incompatibility or even just client-specific reason

* [simeon] management API only has “unknown” and “permissions_increase” as disabledReason, request for more granular reasons to tell why the extension was disabled.
* [rob] If Firefox disables an extension, obviously it knows why. Not clear though on why the extension needs this data.
* [oliver] Reporter gives an example of requesting an update check if disabled for version incompatibility.
* [benjamin] In the case of polymorphic browser attacks, where a browser enables & disables extensions, it would be useful to have and act on that information. For example, when the user's password manager is disabled, you could show a system prompt to notify the user.
* [timothy] This is one of the reasons we don't support the management API currently: malicious uses of the management permission to alter the browser's settings. To mitigate the abuse, if we'd expose it, we'd consider exposing information about an extension authors's own extensions.
* [oliver] I think we'd be open to improving the visibility around extensions modifying the enabled status of other extensions. Regarding this specific request, I don't think we could expose it this way in Chrome, as extensions are not disabled if there is a version incompatibility - we just don't update the extension.
* [simeon] The specific case identified here was with a browser upgrade causing max_stric_version checks to fail.
* [rob] In short, this sounds like a nice to have, but realistically I don't know that we'd have time to work on it.
* [oliver] [Issue 917](https://github.com/w3c/webextensions/issues/917) is related: asks for the introduction of a `management.readOnly` permission. We have a CL open for that.

[PR 942](https://github.com/w3c/webextensions/pull/942): Proposal: i18n.getAvailableLanguages()

* [carlos] Split off from PR 274. I think it makes sense to tackle this separately and possibly earlier.
* [oliver] I suspect that exhaustively returning all supported locales would be difficult. Don't know how it would be rendered by a developer. Might be better to lean on a developer to know what set of languages it supports.
* [timothy] This looks like the intersection of resources the extension has resources for, and the locales that the browser supports.
* [oliver] Given `_locales/en/`, would it return en-US as well?
* [carlos] If there were resource file for en and en-US, both. In the case of a selection menu, it could show en-US and en-GB, but it might not make sense to show a general en, similar to Portuguese.
* [oliver] If you only had an en directory?
* [carlos] Just “en”.
* [rob] How would extensions use this without setLanguage?
* [carlos] I have an extension where I need certain content scripts to match the language of the page itself. This would be used to load a locale file from disk. This would allow the extension to know ahead of time what resources could be fetched.

[Issue 944](https://github.com/w3c/webextensions/issues/944): Feature request: in-memory storage that persists across extension reload/update

* [david] Sounds like they want a secure storage API to hold keys across update?
* [oliver] Slightly different. Reporter wants `browser.storage.session`, but not it cleared in certain cases (extension reload/update). Persistent for the browser session, .
* [timothy] Unclear what the use cases are.
* [david] They mention authentication state, which is why I assumed secure storage.
* [rob] I can see the use case where a user doesn't care that an extension is updated, they just want to avoid reauthenticating unnecessarily. This new kind of storage could help with that.
* [rob] How many storage areas do we want, for each and every use case?
* [oliver] Right, we have other PRs with new storage areas. Can see this getting out of hand.
* [benjamin] From the 1Password perspective, we're surviving without this capability. I don't see a strong need, but I reserve the right to think about it more and change my opinion.
* [rob] A hacky way to achieve the functionality in the update scenario, is to encrypt all data with a temporary key; stash the encrypted data in a browser tab's memory, and the key in the extension storage. As long as they are not both persisted, the data is secure yet persisted for the current browser session across restarts.
* [ben] From the perspective of managing authentication state, I'm willing to do what I can to support advancing secure storage API proposal. This would help us in some use cases I won't get into right now, but I can see this broadly addressing both the use case mentioned in this issue, and many others.
* [benjamin] ++ to secure storage being preferable
* [timothy] Many of these cases would be served by secure storage, we are also already broadly aligned on that proposal.
* [simeon] Sounds like we're aligned, I will take the action item to close this issue.

[Issue 945](https://github.com/w3c/webextensions/issues/945): DNR URL matching and percent encoding

* [simeon] Percent encoding not consistently handled between browsers.
* [rob] FYI: [Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API
* [oliver] Rob had a test verifying consistency of behavior between Firefox and Chrome. This issue suggests that there may be other cases we're not currently covering in tests.
* [simeon] I may take a stab at adding a WPT test to cover this area.
* [rob] That would be nice. I also recently had a case

[PR 932](https://github.com/w3c/webextensions/pull/932): Update runtime.onLoadedReason to match runtime.OnInstalledReason

* [carlos] We talked about this a couple weeks ago.

[Issue 521](https://github.com/w3c/webextensions/issues/521): sidePanel API: sidePanel.close() and sidePanel.toggle()

* [oliver] sidePanel.toggle() suggestion, never discussed. Firefox already supports toggle on the sidebarAction API.
* [oliver] Somewhat apprehensive about adding more methods to sidePanel. Might be good to revisit while discussing the unification of side bar APIs into the one `sidebar` namespace.
* [carlos] Toggle would be useful because we can't currently detect the open state of the side panel.
* [oliver] Would prefer to address the visibility issue.
* [rob] An argument for the toggle API is that opening does currently not work because of the user gesture requirement. Implementing user activation ([issue 918](https://github.com/w3c/webextensions/issues/918)) would address that, right? This would then mean that calling `sidePanel.open()` would work, because user activation is valid for a bit longer than a user gesture.
* [carlos] Potentially yes.
* [timothy] Carlos hinted at there being a race condition around open/close if you have to query first. Having a single method that does the check and action in one shot avoids those cases.

[Issue 422](https://github.com/w3c/webextensions/issues/422): Inconsistency: limits on browser.alarms.create()

* [anton] Checking in to see if we have usage data from Chrome.
* [oliver] 1024 was the limit we discussed last time, which sounds reasonable. Above 100 there is a drop-off. Weird spike between 500 - 1000 characters. Not many above 1000, so 1024 sounds reasonable.
* [simeon] Is it possible to share the numbers on the issue?
* [oliver] I'll check what we can share.
* [simeon] More broadly, I'd like us to try to get some agreed upon guidelines around making breaking changes. For example, what is a low enough usage level to safely make a breaking change?
* [rob] On Firefox we take into account existing usage. It's a bit ad hoc - we evaluate on a case by case basis.

[Issue 463](https://github.com/w3c/webextensions/issues/463): Inconsistency in browser.action: windowId key and enable()/disable() arguments

* [rob] Recently looked into this again because I noticed a difference between Chrome and other browsers. Apparently Firefox was the only browser that threw an error if enable was called with no arguments, so I have fixed that. Do we want to support isEnabled with a number argument? Chrome supports a tabId (number), Safari and Firefox do not (only a dictionary). If we introduced support for a tabId in `isEnabled`, that would be consistent across browsers and compatible with enable/disable.
* [timothy] I'm more inclined to support a dictionary.
* [rob] That would mean `isEnabled` would work with a dictionary, but `enable()`/`disable()` would not. That would be odd, right?
* [timothy] So Chrome supports `isEnabled()` with just a tabId?
* [rob] Yes.
* [timothy] We could potentially support a polymorphic argument. I'd be on board with that if you (Firefox) are.
* [rob] Sounds good, I can make the change this week. Chrome, are you going to file an issue for the dictionary type?
* [oliver] If there's not already a bug I can file one.
* [simeon] Sounds like the next step here is to sketch out a proposal so we're clear on what we're agreeing to.
* [rob] isEnabled behavior is pretty clear, the enable()/disable() behavior was already sketched in the original issue by Timothy.

The next meeting will be on [Thursday, February 12th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=698e6980,3c0).
5 changes: 3 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,25 +10,26 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2026-01-29 at 8 AM PST = https://everytimezone.com/?t=697bf480,3c0
- 2026-02-12 at 8 AM PST = https://everytimezone.com/?t=698e6980,3c0
- 2026-02-26 at 8 AM PST = https://everytimezone.com/?t=69a0de80,3c0

## Past meetings

* 2026-01-29 ([minutes](2026-01-29-wecg.md))
* 2026-01-15 ([minutes](2026-01-15-wecg.md))
* 2025-12-18 ([minutes](2025-12-18-wecg.md))
* 2025-12-04 ([minutes](2025-12-04-wecg.md))
* 2025-11-20 ([minutes](2025-11-20-wecg.md))
* 2025-11-14 at TPAC ([minutes](2025-11-14-wecg-tpac.md))
* 2025-11-13 at TPAC ([minutes](2025-11-13-wecg-tpac.md))
* 2025-11-10 at TPAC ([minutes](2025-11-10-wecg-tpac.md))
* 2025-11-06 ([minutes](2025-11-06-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2026**

* 2026-01-29 ([minutes](2026-01-29-wecg.md))
* 2026-01-15 ([minutes](2026-01-15-wecg.md))

**2025**
Expand Down