Skip to content

Publish minutes of 2025-10-09 meeting #886

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
merged 1 commit into from
Oct 23, 2025
Merged

Publish minutes of 2025-10-09 meeting #886

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
177 changes: 177 additions & 0 deletions _minutes/2025-10-09-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,177 @@
# WECG Meetings 2025, Public Notes, Oct 9

* Chair: Kiara Rose
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=68e84c80,384
Call-in details: [WebExtensions CG, 9th October 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20251009T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #875](https://github.com/w3c/webextensions/issues/875), [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)
* [Issue 843](https://github.com/w3c/webextensions/issues/843): TPAC 2025
* **Triage** (15 minutes)
* [Issue 877](https://github.com/w3c/webextensions/issues/877): Proposal: theme.getCurrent() should always return an effective theme
* [Issue 878](https://github.com/w3c/webextensions/issues/878): Proposal: runtime.getVersion() method
* [Issue 876](https://github.com/w3c/webextensions/issues/876): Add action.restorePopup()
* [Issue 879](https://github.com/w3c/webextensions/issues/879): feature request: browser.cookies.onChanged - return previous cookie properties on overwrite/update
* [Issue 881](https://github.com/w3c/webextensions/issues/881): Proposal: chrome.offscreen.executeScript API for easier DOM access in service worker
* [Issue 882](https://github.com/w3c/webextensions/issues/882): Proposal: WebRequest.securityInfo API for receiving TLS certificate from web requests
* [Issue 884](https://github.com/w3c/webextensions/issues/884): Add action.setBadgeTheme()
* **Timely issues** (10 minutes)
* (an agenda item was listed here, but out of time, so moved to next meeting)
* **Check-in on existing issues** (20 minutes)


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Oliver Dunk (Google)
3. Kiara Rose (Apple)
4. Timothy Hatcher (Apple)
5. Mukul Purohit (Microsoft)
6. Giorgio Maone / ma1 (NoScript, Tor)
7. Benjamin Bruneau (1Password)
8. Simeon Vincent (Mozilla)
9. Oleksii Levzhynskyi (Grammarly)
10. Carlos Jeurissen (Jeurissen Apps)
11. David Johnson (Apple)
12. Tomislav Jovanovic (Mozilla)
13. Casey Garland (Capital One)


## Meeting notes

[Issue 843](https://github.com/w3c/webextensions/issues/843): TPAC 2025

* [kiara] TPAC coming up in November. Plan attendance and agenda.

[Issue 877](https://github.com/w3c/webextensions/issues/877): Proposal: theme.getCurrent() should always return an effective theme

* [kiara] In Firefox getCurrent() does not return the effective theme if the user did not install a custom theme. Safari does not support this API.
* [oliver] This has come up in the past. The reporter submitted a CL with the behavior described in the issue (returning the effective theme).
* https://github.com/w3c/webextensions/issues/680
* [rob] In Firefox, we only return a theme if the user has installed a custom theme. I don't know how feasible it is to always return the “effective theme” because there may be other values that are not easy to encode. For the extension developer, it shouldn't matter if it's a custom theme or a built in one. There's a bug in Firefox about returning a theme where a non-custom theme is used, I would be supportive of fixing that.
* https://bugzilla.mozilla.org/show_bug.cgi?id=1435216
* [oliver] Seems like this is coming from developers a lot, so there's demand for getting the color of the main browser UI. Maybe even just a best effort to get the primary color would be useful. Would need to discuss further with Chrome, but I'm not immediately opposed.
* [kiara] We would have to check how feasible it is on the Safari side.
* [timothy] Hard to say. Definitely complicated with Liquid glass, but was tricky before that given how transparent/blurred materials work. In Safari, setting your background to transparent will give you the default OS styling. I've always been a proponent of the CSS variable approach, but it's tricky.
* [david] For us it's not just per tab, but where on the page you are. We might invert the colors based on content.
* [rob] Supportive on the Firefox side, how about Safari?
* [kiara] Neutral. Not in a rush to support this, but something we'd be open to taking a look at. The developer ask makes sense.

[Issue 878](https://github.com/w3c/webextensions/issues/878): Proposal: runtime.getVersion() method

* [kiara] I believe this was a discussion from our last meeting as it is one of the main use cases for fetching the manifest file.
* [oliver] Also landed in Chromium.
* [rob] And Carlos submitted a patch to Firefox.
* [oliver] Noticed that both Firefox and WebKit return the version by reading the manifest. This is notable because in Chrome we parse the value and as a result it may be different than the value authored. For example, stripping the leading zeros.
* [timothy] We don't do anything with the numbers provided in the manifest.
* [carlos] Is that behavior documented, Oliver?
* [oliver] The version parsing is, but I don't think the fact that we return the parsed version may not be.
* [timothy] Gorhil [raised a question](https://github.com/w3c/webextensions/issues/878#issuecomment-3357270350) about `version_name` - should we do something there?
* [tomislav] Would be surprised if it's actually used for version checks.
* [oliver] While looking into this I saw one case where `version_name` was used, but that was it.
* [kiara] Did you have a sense for what `version` was used for?
* [oliver] … Now that we have getVersion I suspect that getManifest will drop.
* [rob] FYI: In Firefox's MV3 we restricted the version format requirement to bring it closer to what Chrome provided. As part of that effort I did a very thorough comparison of behaviors in Firefox and Chrome (and web stores), and shared details at https://bugzilla.mozilla.org/show_bug.cgi?id=1793925#c3
* [oliver] While looking into this I found a page on MDN that had many nuances of how versions are handled.
* [rob] That may have been based on my comment (linked above).
* [kiara] Is getVersion available in content scripts for Firefox?
* [carlos] Yes.

[Issue 876](https://github.com/w3c/webextensions/issues/876): Add action.restorePopup()

* [kiara] Raised by Carlos. Use case is to restore the popup back to its manifest state.
* [carlos] This is one of the use cases of getManifest in the extensions I maintain. Using `null` or `“”` (empty string) is confusing for developers. Seems to make sense to add more semantic APIs for this kind of use case.
* [timothy] Supportive of this idea, but remember that even if we add this today it still won't ship for maybe a year.
* [rob] What about other browser action properties?
* [carlos] Right, could also have `restoreIcon` and `restoreTitle()`. It would also make feature-detection easier as currently feature detection for setting to null is tricky especially in Safari.
* [timothy] Even if we introduce restorePopup, it will only be available in about 6 months and you would still need to keep existing workarounds for older implementations for the time being.
* [oliver] Right now we don't support null in our API definitions. It gets thrown away before even reaching implementation code. We'd have to take on eng work to support this.
* [rob] I'd be more supportive of a general method to reset all states. Could also reset the value that doesn't match the manifest, since you can change the default at runtime, as there are currently three layers: default from manifest, global set with API, tab-specific.
* [carlos] This wouldn't address the use case I'm targeting. There are just a few (5) methods which are relevant here. Popup would have two methods, removePopup and restorePopup. The remove method would not make sense for many of the other properties.
* [rob] Maybe we should take this offline. Would like to understand why this wouldn't work.
* [simeon] Could add option to specify specific properties.

[Issue 879](https://github.com/w3c/webextensions/issues/879): feature request: browser.cookies.onChanged - return previous cookie properties on overwrite/update

* [kiara] The ask here makes sense to me, but would be tricky to implement in WebKit as we don't currently track that data. Curious for Firefox/Chrome perspective.
* [rob] I see we pass a `removed` property, but that is a boolean. If the information is not already available internally, it may not be easy to implement by browsers.
* [timothy] We don't have the information there.
* [oliver] Saw there were 2 pieces of information, providing both values and guaranteeing the order of the removed/updated events. Were you raising concerns about both?
* [timothy]
* [oliver] I'd be supportive of saying we always fire the remove before the replace event. Or maybe the other way around would make more sense since you wouldn't know why it was removed.
* [timothy] That makes sense.
* [rob] In Firefox we have a consistent order: `cookies.onChanged` with `removed:true` and reason “overwrite”, then `removed:false` and reason “explicit”. But the issue here is requesting previous cookie properties, and that's not something we can easily do.
* [kiara] What would be a good next step? Revisit next meeting after we investigate, or is this something no browser vendors are supportive of.
* [oliver] If this is difficult to implement in both Firefox and Safari, we probably wouldn't want to do it.
* [rob] Order was the concern right? If it's predictable, they can work around it.
* [oliver] If you get two events in quick succession, then as long as the last event that fires has the current value we're good.
* [oliver] I pinged Aaron Selya on the Chrome side who knows about cookies.
* [aaron] I know a bit about the event. I was looking to add some metrics a while ago to see if we could do some history tracking of cookies that were deleted by extensions, but I got busy with other work. I'd have to do more digging to better understand the behavior guarantees. The idea of returning a cookie that has been overwritten seems relatively consistent with some other APIs. For example, if you delete a cookie we return that cookie in the function's return value. Don't know how much utility there is beyond what this person is asking for, but my gut feel is that it doesn't seem unreasonable.
* [oliver] Safari indicated it would be difficult to export, Firefox indicated events are ordered but may not be easy to expose original values.
* [aaron] I wonder if they could just have more than one cookie. It sounds like the use case is syncing values across extensions. They could prefix the cookie with an extension's name. Seems like the cookie store is being used as a pseudo lock, which it wasn't designed for.
* [rob] I looked up [Firefox's lower level implementation](https://searchfox.org/firefox-main/rev/2d38cd5bd7d7958137dd5b4f97aef2f7185a0eb1/netwerk/cookie/CookieStorage.cpp#914-917), and the point that fires the event does already have the old cookie ([link to relevant code in the extension framework implementation](https://searchfox.org/firefox-main/rev/2d38cd5bd7d7958137dd5b4f97aef2f7185a0eb1/toolkit/components/extensions/parent/ext-cookies.js#577,589-591)). So if we all agree we should have the old cookie in the event, we could do so.
* [oliver] On the safari side is this prohibitively difficult to implement or would you be open to adding support if other browsers do?
* [kiara] Haven't had time to look into it, so hard to say at the moment. If other browsers do this, we'd likely want to as well. But can't comment on feasibility without more investigation.
* [oliver] Should we ask the reporter for a concrete proposal with new properties in the events?
* [rob] Could also write down the current order of events and see if that works for them, without requiring more API changes.

[Issue 881](https://github.com/w3c/webextensions/issues/881): Proposal: chrome.offscreen.executeScript API for easier DOM access in service worker

* [timothy] Firefox and Safari do not support offscreen tabs, so this is a Chrome-only issue.
* [oliver] I've personally had this thought in the past and would like this API, but I'm not sure about
* [simeon] Although it is Chrome-only, think that it makes sense to keep track of it for long-term platform evolution.
* [oliver] Is there any interest in general to implement offscreen documents in other browsers? Service worker based extensions can need DOM functionality, which benefit from offscreen document APIs.
* [timothy] Not particularly interested yet since we support background pages in MV3. Curious what the adoption is in Chrome for offscreen documents. Is it widely adopted? Do only a few use it?
* [oliver] Anecdotally most of the bigger extensions that have adopted MV3 use it, mostly out of necessity I expect.
* [timothy] That was my assumption as well. Hard to tease out how much people love it vs. have to use it.
* [oliver] I believe we've said that long term we'd love to not have offscreen documents, but there are a number of features that would need to get supported.
* [rob] We did not adopt this as a “cross-browser API” because from this API's inception, there was always an air of uncertainty around the long term availability and stability of this feature in Chrome.
* [oliver] I wouldn't say it can go away at any time. We'd want a proper deprecation process. But ideally you'd be able to do everything you want to do in a service worker. Recently spoke with a developer that wanted to port their extension to Safari and Firefox, but they couldn't because they had to move their offscreen document logic to the background page.
* [rob] Question regarding the original request, are content scripts injected into pages/iframes loaded in offscreen documents? If Chrome does, this could be a work around.
* [oliver] I'm fairly sure that we do support that.

[Issue 882](https://github.com/w3c/webextensions/issues/882): Proposal: WebRequest.securityInfo API for receiving TLS certificate from web requests

* [kiara] This seemed pretty similar to an existing API in firefox. Is that correct, Rob?
* [rob] We have this, yes. Need to read the request more closely.
* [kiara] I think the developer is asking for a way to get the TLS certificate itself from the securityInfo in a cross-browser way. I believe currently Firefox is the only browser that provides security info on a web request
* [rob] I see, getting the security info from webRequest.onCompleted without having to call a separate API. Initially not opposed.
* [oliver] Could see the utility for extensions that monitor security data, etc.
* [rob] This specific proposal requests an addition to webRequest.onCompleted, but if extensions are interested in requests that are not the final request, the proposal may not cover it.
* [timothy] Not sure how feasible this would be for Safari. We have the data somewhere, but don't know how much plumbing it would take or where it would come from.
* [rob] Is onHeadersReceived a feasible place to expose this data?
* [timothy] I think so. And to your point we'd want to do it there because of the redirects, right?
* [rob] The reporter suggested this may not be the right event, but I don't understand why.
* [oliver] Would onBeforeHeaders work? There's some suggestion in the Chrome docs that some of this data may be available after the TCP connection is established, but before the headers are received.
* [rob] onBeforeSendHeaders is too early, onHeadersReceived is the next event in the request cycle and the first documented event that is guaranteed to have the necessary information (because a response can only be received once a connection has been established).
* [timothy] Would this be easier to implement as a new event because of feature detection?
* [rob] To support feature detection, we could add a new property/enum value accepted by `extraInfoSpec`, similar to how webRequest.ResourceType has members for specific properties. A new event may be useful, regardless.
* [timothy] I'm more in favor of a separate event so we can fire as soon as we have the info in the right spot instead of waiting/delaying for when it comes through. Depends on where our network stack allows us to expose it. Also makes this feature detectable.
* [simeon] Still feature detectable in an extraInfoSpec string, right? Registration throws, you catch. More awkward than I'd like but feasible.
* [timothy] We don't throw in that case.
* [rob] Firefox and Chrome do, but not Safari.

[Issue 884](https://github.com/w3c/webextensions/issues/884): Add action.setBadgeTheme()

* [carlos] Currently there are two methods to change badge theming: setTextColor and setBadgeColor. Possible that these can result in a flash of partially applied update state. Would be preferable to set dark and light values together so they are applied simultaneously. I have two proposals
* [simeon] Surprised that updates can be partially applied between the two calls. Expectations from DOM are that updates that don't require re-render will be batched and applied together.
* [timothy] DOM case, but optimistic to assume the browser UI to do the same.
* [carlos] Changing the text without color can result in flickering issues.
* [rob] I think in the sidebar discussions we were aligning on applying multiple updates in a single call.
* [carlos] You can't necessarily set everything at the same time. They are different update scenarios.
* [rob] Right, you would omit things you don't want to change. It would be a partial update.
* [carlos] Not sure creating unified set/restore API simplifies the situation. Say you add a new syntax for a specific variable, you'd need to determine which value is not supported in a given browser based on an error message (if it even gives an error), then change the call. From a developer perspective it creates more complications than it solves.
* [rob] Shape of the API can be discussed. I'd be supportive of being able to set multiple properties in one call.
* [timothy] Supportive of setting all theme values at once like icon_variants, because it forces extension developers to set everything all at once, so that the browser has all information available when needed, especially useful with Liquid Glass.
* [kiara] Out of time, we can revisit this discussion at the next meeting.

The next meeting will be on [Thursday, October 23rd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68fac180,384). This overlaps with the Ad Filtering Dev Summit event ([issue 844](https://github.com/w3c/webextensions/issues/844)).
4 changes: 3 additions & 1 deletion _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2025-10-09 at 8 AM PDT = https://everytimezone.com/?t=68e84c80,384
- 2025-10-23 at 8 AM PDT = https://everytimezone.com/?t=68fac180,384
- 2025-11-06 at 8 AM PST = https://everytimezone.com/?t=690d3680,3c0

## Past meetings

* 2025-10-09 ([minutes](2025-10-09-wecg.md))
* 2025-09-25 ([minutes](2025-09-25-wecg.md))
* 2025-09-11 ([minutes](2025-09-11-wecg.md))
* 2025-08-28 ([minutes](2025-08-28-wecg.md))
Expand All @@ -27,6 +28,7 @@ After the end of each meeting, meeting notes are published here.

**2025**

* 2025-10-09 ([minutes](2025-10-09-wecg.md))
* 2025-09-25 ([minutes](2025-09-25-wecg.md))
* 2025-09-11 ([minutes](2025-09-11-wecg.md))
* 2025-08-28 ([minutes](2025-08-28-wecg.md))
Expand Down