Skip to content

Publish minutes of 2025-10-23 meeting #894

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
Nov 6, 2025
+161 −2
Merged

Publish minutes of 2025-10-23 meeting #894

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

* Chair: Simeon Vincent
* Scribes: Rob Wu

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


## Agenda: [discussion in #887](https://github.com/w3c/webextensions/issues/887), [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)
* [[wg/webextensions] Web Extensions Working Group strategy#146](https://github.com/w3c/strategy/issues/146) and Simeon is iterating on revisions in [w3c/charter-drafts#/711](https://github.com/w3c/charter-drafts/pull/711) .AFDS in Cyprus, October 23—24
* TPAC is coming up! Suggest topics in
* [WECG at TPAC 2025 #843](https://github.com/w3c/webextensions/issues/843) or tag that issue in comments on other issues.
* [WEWG charter draft](https://w3c.github.io/charter-drafts/2025/webextensions-wg.html) is being discussed in
* **Triage** (15 minutes)
* [PR 885](https://github.com/w3c/webextensions/pull/885): Correct iconVariants and colorSchemes casing.
* [PR 883](https://github.com/w3c/webextensions/issues/883): Proposal: initial_permissions and initial_host_permissions Add mention to NotificationOptions
* [Issue 889](https://github.com/w3c/webextensions/issues/889): Cache web extension byte code
* [Issue 890](https://github.com/w3c/webextensions/issues/890): Standardize document id
* [Issue 891](https://github.com/w3c/webextensions/issues/891): scripting.exectuteScript does not work in tabId === -1
* [Issue 892](https://github.com/w3c/webextensions/issues/892): Real estates for accessible communication with the user
* **Timely issues** (10 minutes)
* [PR 873](https://github.com/w3c/webextensions/pull/873): Add specification for externally_connectable
* [Issue 882](https://github.com/w3c/webextensions/issues/882): Proposal: WebRequest.securityInfo API for receiving TLS certificate from web requests (added 23/10/25 by @oliverdunk)
* **Check-in on existing issues** (20 minutes)
* (None)


## Attendees (sign yourself in)

1. Mukul Purohit (Microsoft)
2. Tomislav Jovanovic (Mozilla)
3. Simeon Vincent (Mozilla)
4. Oleksii Levzhynskyi (Grammarly)
5. Benjamin Bruneau (1Password)
6. Giorgio Maone (NoScript, Tor)
7. Rob Wu (Mozilla)
8. Andreas Wagner (Mozilla)
9. Krzysztof Modras (Ghostery)
10. David Vaisbrud (LayerX)
11. Oliver Dunk (Google)
12. David Johnson (Apple)
13. Timothy Hatcher (Apple)
14. Carlos Jeurissen (Jeurissen Apps)


## Meeting notes

[PR 885](https://github.com/w3c/webextensions/pull/885): Correct iconVariants and colorSchemes casing. Add mention to NotificationOptions

* [carlos] This covers the use of `iconVariants` and `colorSchemes` in manifest files. Snake case was used in the manifest and Safari's initial implementation of the JS APIs. This PR updates the proposal to use camel case as is common on the platform.
* [tomislav] Saw that Timothy added comments.
* [timothy] Kiara made this change last week. We shipped support for both keys for backwards compatibility. Don't think anyone is currently snake case, but just in case we don't want to break anyone.
* [oliver] Seems reasonable to me. Will run by the eng team
* [carlos] Can we get this merged?
* [tomislav] Want to give Oliver time to discuss with his team before landing.
* [oliver] I believe we normally do two browsers say yes can merge, so not a blocker.

[PR 883](https://github.com/w3c/webextensions/issues/883): Proposal: initial_permissions and initial_host_permissions

* [carlos] Competing proposal to address the way new permissions are handled on update and address automatic hoisting of content script host permissions, allowing to declare more content scripts declaratively. This proposal helps ensure that (host) permissions updates are backwards compatible. Permissions specified in initial_permissions will only apply in new installations and be handled as optional for others.
* [tomislav] Are you referring to [PR 798](https://github.com/w3c/webextensions/pull/798) as the previous issue?
* [carlos] Yes.
* [oleksii] I have a clarifying question. But generally supportive of approaches that are backwards compatible.
* [tomislav] There are a couple of points in discussions including a point raised by @fregante.
* [rob] Curious about perspective from Google. Previously there was concern raised around specifying all permissions in multiple keys.
* [oliver] I remember Devlin raising that concern. I don't generally share as much, but we should definitely discuss it more among Chrome eng.
* (To revisit at a later meeting.)

[PR 873](https://github.com/w3c/webextensions/pull/873): Add specification for externally_connectable

* [david] Kiara isn't here to speak to this, but the PR is open and we welcome feedback.
* [tomislav] Mostly for Google as we don't implement this. Don't consider us a blocker.
* [rob] I'll take care of the review on Mozilla's side as I have the most context on it. There's a request for implementation in Firefox where I left many comments (https://bugzilla.mozilla.org/show_bug.cgi?id=1319168).

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

* [vlad] Request from developers to build connection strength meter and other enterprise users. Firefox already has something like this, but in a different shape. Is Safari interested in this API?
* [tomislav] Differences between Firefox version and what you're requesting?
* [vlad] Chrome changed web request filtering in MV3. In Firefox it is based on a blocking model. In Chrome this blocking API is unavailable. So this shape cannot work, but the functionality is the same.
* [rob] The requested functionality can be fitted in the API, even without webRequestBlocking. E.g. if the developer opts into it with extraInfoSpec (or does not, Firefox does not require that for example), the browser can keep the certificate information in memory, in case extensions want to request the information, until the event has been handled. There is precedent for extra information via extraInfoSpec, e.g. responseHeaders, but that is push-based instead of pull-based. Browser can continue to handle the request and (without blocking the request) keep the certificate around until it is certain that relevant extensions have used or ignored the certificate.
* [oliver] Don't think we currently have a method on the webRequest API to get data on a request. Regardless of the proposal you just raised, Rob, or previous specs, we want to have a consistent structure for the data.
* [vlad] Currently I don't think we can keep it fully compatible.
* [oliver] We had some discussions around request chains, but were there other differences?
* [vlad] An important difference is that Firefox exposes a certificates field. As a dev, you don't know if its certs that the server sent or of the browser assembled a chain.
* [rob] We can agree on what it should be. An unambiguous interpretation could be able to look at the certificates from the TLS handshake. These kinds of details can be ironed out in the spec. Possible that the outcome is Firefox makes a change to something if another approach makes more sense.
* [tomislav] Could also add additional fields to specify if there are multiple approaches that make sense.
* [vlad] To clarify, in your opinion all of these objects should be 100% compatible?
* [tomislav] As much as it makes sense. We try to be as compatible as reasonably possible.
* [krzysztof] Should this proposal included also a way to block requests with mismatched certificates. For privacy and security perspective this would has to be declarative approach so that we guarantee requests are blocked before the leave the browser.
* [vlad] Would probably want to do that separately. Want to make sure that whatever we do can be safely extended in the future.
* [timothy] If we implement this, we'd probably want to do it both ways in Safari.
* [tomislav] As Rob said, if there are insufficiencies we're open to changing what we return. Not sure if you saw, but we have a proposal template in the repo. Suggest following up in the next meeting with a proposal after additional consideration of the points raised here.
* [vlad] Okay, I'll research it more.

[Issue 889](https://github.com/w3c/webextensions/issues/889): Cache web extension byte code

* [krzysztof] Quick note that I brought back from the WECG meetup we had earlier this year. Looks like web extension scripts aren't cached by browsers. Incurs overhead of fetch, parse, execute on every script. May significantly improve web extension performance. Slowdowns are very visible in certain browsers. Wondering if there's an opportunity for a systematic approach.
* [rob] As noted in the issue, this is a browser-specific implementation without there being much to discuss in the group as there's no developer visible (API) impact. It does make sense to implement the optimization, however.
* [timothy] Didn't mean to be dismissive in the comment. Definitely interested in exploring this performance issue in Safari. Stand by that there's not much to do in the group here other than to suggest it as a possible optimization to participating browser vendors.
* [rob] If you can share more details, that would help make a more compelling case for working on these optimizations.
* [tomislav] There's some overlap with web API in how service workers behave. Might be worth saying as an explicit non-goal that we don't want to expose the cache of these resources to service worker APIs, but that may be a separate issue.
* [oliver] agree that this may be out of scope, but worth noting in Chrome that we support the service worker APIs.
* [timothy] But that's resource caching, not bytecode caching.
[Issue 890](https://github.com/w3c/webextensions/issues/890): Standardize document id

* [krzysztof] Came up while working on our extension. Occurred to me that this is going to become more complicated as browsers support multiple documents per tab. `documentId` may offer a more systematic approach. Given the current state of webExt APIs, I don't think we're ready for split views. Tab APIs and web navigation APIs need to be expanded. Not sure if Firefox is currently treating split views correctly.
* [rob] documentId in scripting API was discussed before, at: https://github.com/w3c/webextensions/issues/91
* [rob] We are working on split views at the browser level and extension APIs are considered as part of that work. What part of the API is missing in the existing split view proposal (merged in [PR 842](https://github.com/w3c/webextensions/pull/842))?
* https://github.com/w3c/webextensions/blob/main/proposals/split_tabs_proposal.md
* [krzysztof] Will review that & provide feedback. Just came up recently as we were working on this. Broadly, I'm asking that Firefox and Safari adopt the documentId implementation seen in Chrome.
* [timothy] Safari shipped an implementation of documentId in 18, so it has been out for about a year.
* [tomislav] What's the next step here? If you can, go through the existing things to see what Chrome has implemented and what's missing from the existing proposal.
* [krzysztof] Okay, thanks.
* [simeon] Could also create a list of documentId tests for WPT.
* [rob] That would help. Having a list of APIs that should documentId could be helpful for implementers, but on the other hand Chromium and WebKit are open source and it is easy to look up which APIs are expected to support it. If there are differences it could be a good point of discussion.

[Issue 891](https://github.com/w3c/webextensions/issues/891): scripting.executeScript does not work in tabId === -1

* [rob] Duplicate of [issue 91](https://github.com/w3c/webextensions/issues/91)?
* [simeon] The request was specifically about off screen document, [issue 881](https://github.com/w3c/webextensions/issues/881).
* [krzysztof] Not just top-level offscreen, but also iframes and prerender.
* [rob] documentId would address that as well.
* [carlos] Would it not be better to get the documentId of the offscreen document and pass that into executeScript? That would close both 881 and 891 in favor of 91.
* [rob] supportive. More a question for Google since they are the only implementers of offscreenDocuments.
* [oliver] +1.
* [oliver] Even if we had a documentId, scripting.executeScript currently requires a documentId. Would be weird to require -1 in this case.
* [rob] That aspect is also covered by issue 91.
* [timothy] Could be multiple documents.
* [krzysztof] Seems like documentId fulfills this quite well, assuming we have a way of querying each iframe in the hierarchy.
* [oliver] Are documentIds unique across tabs?
* [rob] We agreed on it being globally unique.
* [oliver] Should update scripting.executeScript to accept either a documentId or a tabId, then.
* [tomislav] I think we previously were discussing either a tabId or another identifier so the intention is clear.
* [carlos] https://github.com/w3c/webextensions/issues/91#issuecomment-2010569435
* [timothy] Agree that documentId is probably enough without tabId or anything else.

[Issue 892](https://github.com/w3c/webextensions/issues/892): Real estates for accessible communication with the user

* [krzysztof] Just another note that I brought from the WECG meetup in Berlin earlier this year. We briefly discussed that extensions may need some additional real estate to get in front of the user beyond spawning new tabs or creating windows to get in front of users. Idea is we could have a surface to place messages in front of users without being annoying. Don't want extensions to interrupt user actions.
* [tomislav] Noble idea, unfortunate reality is that extensions teams usually don't own those surfaces in browsers. Not always up to us to choose where things show up, how long they stay, etc. Unless this is something very optional, where it could be shown or not depending on user settings, it could be very difficult to align on a cross-browser approach. If we said it was a best effort feature, we may have more flexibility in how we approach it.
* [krzysztof] Perfectly understandable. Counterpoint, in today's Chrome talk at AFDS, Chrome showed a UI to acquire extra host permissions. That would be real estate that's close to an extension itself and can be used to help get a user's attention.
* [oliver] That was the addHostAccessRequest API. Would like to see extensions get more UI surfaces. Over the years there have been experiments showing more or less UI. Would be hesitant about committing to additions. I can see difficulties trying to expand the use of something like the host permission request dialog for more content.
* [rob] FYI: addHostAccessRequest was designed in the WECG before implementation at https://github.com/w3c/webextensions/blob/main/proposals/permissions-addHostAccessRequest-api.md
* [krzysztof] If we don't come up with a systematic solution, we'll continue to see extensions creating obtrusive, distracting, or annoying solutions.
* [timothy] Would love to explore this. Would love a way to get extensions out of the page, so they don't have to inject.
* [rob] Personally, would be interested in some kind of feed where extensions can notify users, even if only displayed in the extensions management page (chrome://extensions/ in Chrome, about:addons in Firefox).
* [tomislav] I think we all agree this is a problem we'd like to see addressed.

The next meeting will be on [Thursday, November 6th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=690d3680,3c0). Note: Daylight saving time change (PDT to PST). Effectively at the same time for US and EU people.
6 changes: 4 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,18 +3,19 @@
The [WebExtensions Community group](https://www.w3.org/community/webextensions/) meets virtually every other week, for one hour.
The instructions to join the meeting and agenda are available at https://www.w3.org/groups/cg/webextensions/calendar.

* Thursday 8 AM PDT (3 PM UTC)
* Thursday 8 AM PST (4 PM UTC)
* To convert to your local time zone, see https://everytimezone.com/

After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 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
- 2025-11-20 at 8 AM PST = https://everytimezone.com/?t=691fab80,3c0

## Past meetings

* 2025-10-23 ([minutes](2025-10-23-wecg.md))
* 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))
Expand All @@ -28,6 +29,7 @@ After the end of each meeting, meeting notes are published here.

**2025**

* 2025-10-23 ([minutes](2025-10-23-wecg.md))
* 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))
Expand Down