Skip to content

Publish minutes of 2026-05-21 meeting #1002

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

Open
Rob--W wants to merge 1 commit into
base: main
Choose a base branch
from
+171 −2
Open

Publish minutes of 2026-05-21 meeting #1002

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
168 changes: 168 additions & 0 deletions _minutes/2026-05-21-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,168 @@
# WECG Meetings 2026, Public Notes, May 21

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=6a0f9c80,384
Call-in details: [WebExtensions CG, 21st May 2026](https://www.w3.org/events/meetings/6a0eda89-558c-408d-b83d-5f03b8853c30/20260521T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #998](https://github.com/w3c/webextensions/issues/998), [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)
* The [WebExtensions Working Group](https://www.w3.org/groups/wg/webextensions/) exists! Here's the [Call for Participation](https://lists.w3.org/Archives/Public/public-webextensions/2026May/0000.html).
* [tomislav] Mozilla is hiring on the WebExtensions team:
* https://www.mozilla.org/en-US/careers/position/gh/7921746/
* [david] Apple is also hiring for the Safari Extensions team:
* https://jobs.apple.com/en-us/details/200634673-3543/software-engineer-safari-extensions?team=SFTWR
* **Triage** (15 minutes)
* [Issue 999](https://github.com/w3c/webextensions/issues/999): Proposal: "name" attribute in second argument of alarms.create()
* [Issue 1000](https://github.com/w3c/webextensions/issues/1000): PSA: Google Chrome 149 will be the last version fully supporting MV2 and Blocking WebRequest
* [PR 1001](https://github.com/w3c/webextensions/pull/1001): Add issue requirement to proposal process
* **Timely issues** (10 minutes)
* [PR 989](https://github.com/w3c/webextensions/pull/989): Proposal: Asynchronous Listener Registration
* **Check-in on existing issues** (20 minutes)
* [Issue 848](https://github.com/w3c/webextensions/issues/848): Proposal: Allow Document Picture-in-Picture from Offscreen Documents in WebExtensions
* [Issue 683](https://github.com/w3c/webextensions/issues/683): Feature request. More granular Extension's hotkeys scope
* [A comment](https://github.com/w3c/webextensions/commit/e08950c581969e45f6953e378e25abdb4ec2e410#r179939977) on [PR 852](https://github.com/w3c/webextensions/pull/852): Proposal: browser.test API
* [A comment](https://github.com/w3c/webextensions/issues/337#issuecomment-4462194115) on [Issue 337](https://github.com/w3c/webextensions/issues/337#issuecomment-4462194115): Inconsistency: CSP for inline web page elements added by extension
* [rob] publicSuffix.getVersion
* **Housekeeping** (2 minutes)
* remove `topic: run on click` (is same as topic: activetab)
* remove `needs-triage` (replaced with engine specific labels)
* rename `topic: dnr` to `topic: dnr and webRequest` or `topic: network mutations` or something similar. So it applies to both dnr and webRequest


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Benjamin Bruneau (1Password)
3. Tim Judkins (Google)
4. Simeon Vincent (unaffiliated)
5. Ben Greenberg (Aglide)
6. Brandon Lucier (1Password)
7. Timothy Hatcher (Apple)
8. Carlos Jeurissen (Jeurissen Apps)
9. Oliver Dunk (Google)
10. Anton Bershanskyi (Independent)
11. Mukul Purohit (Microsoft)
12. David Johnson (Apple)
13. Tomislav Jovanovic (Mozilla)


## Meeting notes

Announcement: WebExtensions Working Group

* [simeon] The [WebExtensions Working Group](https://www.w3.org/groups/wg/webextensions/) exists! Here's the [Call for Participation](https://lists.w3.org/Archives/Public/public-webextensions/2026May/0000.html), you can join if you are an official W3C member. Tentative plan is to meet in the off week when we do not have WECG meetings. WECG continues to serve its existing purpose, WEWG focus is on specification and implementation consistency.

[Issue 999](https://github.com/w3c/webextensions/issues/999): Proposal: "name" attribute in second argument of alarms.create()

* [anton] `alarms.create` takes 2 arguments, suggest to accept the argument in the dictionary. Just a syntax suggestion.
* [rob] Sounds good. We have had discussions on restricting name length etc; if any implementation was being permissive before (maybe for backwards compatibility), this new property should enforce these restrictions with a hard error.
* [oliver] update on [issue 406](https://github.com/w3c/webextensions/issues/406) - Chrome now supports the persistAcrossSessions flag in the alarms API.
* [rob] Saw that and was considering to write a patch for Firefox, but the question is what does persistent mean? Not clear what Firefox's behavior should be. If you can, please add a description of expected behaviors.
* [oliver] Can do. Short answer is persisted until update, cleared on update.
* [rob] Other questions around what if the clock shifts while the browser isn't running.

[Issue 1000](https://github.com/w3c/webextensions/issues/1000): PSA: Google Chrome 149 will be the last version fully supporting MV2 and Blocking WebRequest

* [anton] Chrome internal, but relevant to extension developers: Chrome CL with plan to remove MV2 implementation from Chrome.
* [rob] Issue says MV2 and blocking web request. MV2 is clear, but blocking web request is, to my knowledge, available to enterprise installed extensions.
* [oliver] blocking webRequest is still supported for policy installed extensions, no intent to change that.
* [rob] I will update the issue after publishing the meeting notes.
* [simeon] Point of order: since this is a general awareness raising issue, I suggest closing it after a couple weeks.
* [rob] Glad Anton raised this due to its impact on extension developers, a worthy candidate for Issue One Thousand.
* [carlos] Should consider how we handle cases like this in MV4+.
* [timothy] Safari has no intention to drop support vor MV2, but we've never supported WebRequestBlocking.
* [rob] No plans in Firefox to deprecate MV2 or webRequestBlocking

[PR 1001](https://github.com/w3c/webextensions/pull/1001): Add issue requirement to proposal process

* [carlos] We discussed this two weeks ago. This PR adds the issue requirement clear in the proposal process docs.
* [rob] Looks good to me.

[PR 989](https://github.com/w3c/webextensions/pull/989): Proposal: Asynchronous Listener Registration

* [rob] Andrea has updated the PR and has approval for me and Timothy. I think we can merge. For those not following it, this allows extensions to delay event dispatch until async listeners are able to register. Doesn't replace synchronous listeners.
* [carlos] Is there a proposed timer for failing to register?
* [rob] No. Extension will be obviously broken.
* [oliver] Service worker timeout still applies in Chrome.

[Issue 848](https://github.com/w3c/webextensions/issues/848): Proposal: Allow Document Picture-in-Picture from Offscreen Documents in WebExtensions

* [rob] This issue was nominated for the agenda because a comment was posted after the issue was closed.
* [oliver] Offscreen documents are a Chrome-only feature.
* [rob] Question - if an offscreen document triggers UI, e.g. a file picker, would it show up?
* [oliver] By default no, but we have certain carve-outs, like alert(), where developers use this capability a lot.
* [rob] I see Firefox is shipping support for PiP. We don't have offscreen documents, but the question of exposing this in event pages is still relevant. Someone needs to test this.
* [tim] I can look into the behavior here in Chrome and report back.
* [rob] This issue was discussed before but without Google present ([2025-07-17-wecg.md](https://github.com/w3c/webextensions/blob/main/_minutes/2025-07-17-wecg.md#meeting-notes)).
* [simeon] I will rename the issue to make it more generic, covering other browsers without offscreen documents.

[Issue 683](https://github.com/w3c/webextensions/issues/683): Feature request. More granular Extension's hotkeys scope

* [carlos] toph asked what they should do if they want to only support hotkeys for specific web pages and not extension pages.
* [oliver] On the Chrome side we'd be unlikely to implement more scoping for registered
* [rob] Initial thoughts on seeing Toph's comment was that in theory we could add more scoping. I have an idea that seems more feasible than the original proposal of scoping.
* [oliver] With match patterns this may be more complicated.
* [rob] Shortcut would still be consumed, it just wouldn't activate. If you declare a command with `_execute_action` command and match patterns for certain domains, it would only trigger for commands triggered while a content area (or tab) is focused that matches the URL.
* [timothy] I think the shortcut would still be consumed without fallback. I also agree that match patterns would be acceptable for us in Safari, to allow extensions to declare shortcuts declarative.
* [rob] At the same time, extensions can query based on data passed to the event where it was triggered. If match patterns was the only capability we'd consider, I think we can save the effort and let extensions handle it themselves.
* [timothy] In Safari we show commands in the menu bar. If we had the signal of a match pattern list, we could show enabled/disabled in the menu bar. Gives the user another signal that it will/wont work. I see value in adding support.
* [simeon] Does Firefox show the keyboard shortcut for menu items?
* [rob] Not for extension defined commands.
* [timothy] We show all extension commands in the menu bar with associated keyboard shortcut. As Oliver said, if disabled it wouldn't fall back to another extension if it is disabled.
* [rob] Could be confusing to the user that their shortcut is consumed without visible UI. I suggest we keep the issue closed. Would be nice to have an API to have context-specific shortcuts, but not feasible at the moment.
* [timothy] No objection to keeping it closed.

[PR 852](https://github.com/w3c/webextensions/pull/852): Proposal: browser.test API

* ([comment](https://github.com/w3c/webextensions/commit/e08950c581969e45f6953e378e25abdb4ec2e410#r179939977)) “could you confirm if omitting self and args from the assertThrows signature was a deliberate choice? Chromium's chrome.test API includes them: `assertThrows(fn, self, args, message)` ([source](https://source.chromium.org/chromium/chromium/src/+/main:extensions/renderer/resources/test_custom_bindings.js;l=416;drc=3a5dfa349b5eb877e8febcd897f9998ab34c8709)).”
* [rob] Note that you have to log into GitHub in order to see this comment.
* [rob] In any case, the answer is: `assertThrows` intentionally does not take an argument that takes `self` and `args` because modern JS syntax can serve the same purpose with arrow functions.

[Issue 337](https://github.com/w3c/webextensions/issues/337#issuecomment-4462194115): Inconsistency: CSP for inline web page elements added by extension

* ([comment](https://github.com/w3c/webextensions/issues/337#issuecomment-4462194115)) “@lapcat Seems related to #982. Chrome content scripts are more privileged.
Updated your demo with a direct sample site (https://cookicons.co), and tested in all browsers. Seems Chrome is the odd one here:　https://jeurissen.co/webext-demos/content-script-js-injected-css-font-loading”
* [carlos] Seems like it may be a duplicate of [issue 982](https://github.com/w3c/webextensions/issues/982). … I believe we discussed this in 2023. In general, do we want content scripts to have some kind of escalation
* [rob] Don't think it's a duplicate of 982, but related. I think it makes sense to use the web page's policy wherever possible. Main argument for CSP in content script is to enforce script restrictions. Everything else we try to respect the page's CSP wherever possible.
* [timothy] I recall there was an effort to have CSP for extension content scripts in Chrome. Might be a holdover from that that never got fully removed.
* [carlos] lapcat also mentions that Firefox does not support adoptedStyleSheets from content scripts without using wrappedJSObject.
* [rob] That behavior with `adoptedStyleSheets` will be fixed soon, I put up a patch for that at: https://bugzilla.mozilla.org/show_bug.cgi?id=1751346.

Housekeeping

* remove `topic: run on click` (is same as topic: activetab)
* [simeon] run on click is a specific behavior. Is it used?
* [carlos] Doesn't look like it is.
* [simeon] Maybe it's best to delete it then.
* remove `needs-triage` (replaced with engine specific labels)
* [simeon] Deleted!
* rename `topic: dnr` to `topic: dnr and webRequest` or `topic: network mutations` or something similar. So it applies to both dnr and webRequest
* [simeon] Currently namespace based topics rather than
* [rob] Could keep DNR and expand the description to say it covers webRequest.
* [timothy] I would rather have webRequest as a separate topic.

publicSuffix.getVersion

* [rob] Firefox has received a patch for the publicSuffix API (proposed in [PR 676](https://github.com/w3c/webextensions/pull/676)). One aspect is the `getVersion`, but the PSL maintainer at Mozilla is not a fan of introducing the method. The method was originally added [based on feedback from Oliver](https://phabricator.services.mozilla.com/D295513#10264666), citing PSL maintainer preference, but it appears that PSL maintainers are not in favor of the method. Shall we drop `publicSuffix.getVersion()`?
* [oliver] I recall having an email thread with PSL maintainers, but don't recall with who. I don't have strong feelings, but someone requested we include this as part of the PR.
* [rob] I am aware of a request for version in the PSL data at https://github.com/publicsuffix/list/issues/1808, but is there also a request for including the version in the API?
* [oliver] Yes. I'll follow up internally to track this down. I think the value is that if there are cases where you're using your own version of the PSL, you can make sure you're in sync.
* [rob] That's a potential use case, but the main purpose of the API is to make sure the extension and browser have the same understanding of the PSL.
* [oliver] A bit contrived, but say you have a copy of the PSL in a WASM module.
* [rob] In that case I’d suggest importing the publicSuffix API to the WASM instance for a consistent view of the PSL. In any case, I would like to get feedback from the PSL maintainers.

Final announcements

* Mozilla is hiring a WebExtensions engineer. https://www.mozilla.org/en-US/careers/position/gh/7921746/
* Apple is hiring for the Safari Extensions team. https://jobs.apple.com/en-au/details/200634673-3543/software-engineer-safari-extensions

The next meeting will be on [Thursday, June 4th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6a221180,384).
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-05-21 at 8 AM PDT = https://everytimezone.com/?t=6a0f9c80,384
- 2026-06-04 at 8 AM PDT = https://everytimezone.com/?t=6a221180,384
- 2026-06-18 at 8 AM PDT = https://everytimezone.com/?t=6a348680,384

## Past meetings

* 2026-05-21 ([minutes](2026-05-21-wecg.md))
* 2026-05-07 ([minutes](2026-05-07-wecg.md))
* 2026-04-23 ([minutes](2026-04-23-wecg.md))
* 2026-04-09 ([minutes](2026-04-09-wecg.md))
* 2026-04-09 F2F meetup in London ([minutes](2026-04-09-london-f2f.md))
* 2026-04-08 F2F meetup in London ([minutes](2026-04-08-london-f2f.md))
* 2026-04-07 F2F meetup in London ([minutes](2026-04-07-london-f2f.md))
* 2026-03-26 ([minutes](2026-03-26-wecg.md))
* 2026-03-12 ([minutes](2026-03-12-wecg.md))

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

**2026**

* 2026-05-21 ([minutes](2026-05-21-wecg.md))
* 2026-05-07 ([minutes](2026-05-07-wecg.md))
* 2026-04-23 ([minutes](2026-04-23-wecg.md))
* 2026-04-09 ([minutes](2026-04-09-wecg.md))
Expand Down