|
| 1 | +# WECG Meetings 2026, Public Notes, May 7 |
| 2 | + |
| 3 | + * Chair: Kiara Rose |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=69fd2780,3c0 |
| 7 | +Call-in details: [WebExtensions CG, 7th May 2026](https://www.w3.org/events/meetings/6a0eda89-558c-408d-b83d-5f03b8853c30/20260507T080000/) |
| 8 | +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) |
| 9 | + |
| 10 | + |
| 11 | +## Agenda: [discussion in #988](https://github.com/w3c/webextensions/issues/988), [github issues](https://github.com/w3c/webextensions/issues) |
| 12 | + |
| 13 | +The meeting will start at 3 minutes after the hour. |
| 14 | + |
| 15 | +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. |
| 16 | + |
| 17 | + * **Announcements** (2 minutes) |
| 18 | + * **Triage** (15 minutes) |
| 19 | + * [Issue 551](https://github.com/w3c/webextensions/issues/551): Proposal: browser.commands.clear() to clear browser shortcuts |
| 20 | + * [Issue 306](https://github.com/w3c/webextensions/issues/306): scripting.InjectionTarget.workers property to inject WorkerScope(s) |
| 21 | + * [Issue 94](https://github.com/w3c/webextensions/issues/94): Support for wildcards in externally_connectable.matches |
| 22 | + * [Issue 991](https://github.com/w3c/webextensions/issues/991): Add ability to disable extension on specific sites with MV3 |
| 23 | + * **Timely issues** (20 minutes) |
| 24 | + * [PR 975](https://github.com/w3c/webextensions/pull/975): Update runtime.onInvalidated with unload reason and isolated world restriction |
| 25 | + * [PR 989](https://github.com/w3c/webextensions/pull/989): Proposal: Asynchronous Listener Registration |
| 26 | + * [Issue 994](https://github.com/w3c/webextensions/issues/994): Inconsistency: `commands._execute_action.description` |
| 27 | + * [Issue 995](https://github.com/w3c/webextensions/issues/995): Allow extensions to query the list of languages it supports (ie, i18n.getAvailableLanguages()) |
| 28 | + * **Check-in on existing issues** (10 minutes) |
| 29 | + * (more topics were nominated for the agenda, but not discussed and moved to next week) |
| 30 | + |
| 31 | + |
| 32 | +## Attendees (sign yourself in) |
| 33 | + |
| 34 | + 1. Rob Wu (Mozilla) |
| 35 | + 2. Tim Judkins (Google) |
| 36 | + 3. Andrea Orru (Google) |
| 37 | + 4. Hilary Hacksel (1Password) |
| 38 | + 5. Timothy Hatcher (Apple) |
| 39 | + 6. Giorgio Maone (NoScript, Tor) |
| 40 | + 7. Krzysztof Modras (Ghostery) |
| 41 | + 8. Kiara Rose (Apple) |
| 42 | + 9. Casey Garland (Capital One) |
| 43 | + 10. Carlos Jeurissen (Jeurissen Apps) |
| 44 | + 11. David Hénot (Dashlane) |
| 45 | + 12. Ben Greenberg (Aglide) |
| 46 | + 13. Maxim Topciu (AdGuard) |
| 47 | + 14. Benjamin Bruneau (1Password) |
| 48 | + 15. David Johnson (Apple) |
| 49 | + 16. Simeon Vincent (Unaffiliated) |
| 50 | + 17. Mukul Purohit (Microsoft) |
| 51 | + |
| 52 | + |
| 53 | +## Meeting notes |
| 54 | + |
| 55 | +[Issue 551](https://github.com/w3c/webextensions/issues/551): Proposal: browser.commands.clear() to clear browser shortcuts |
| 56 | + |
| 57 | + * [carlos] We never triaged this issue, so I put this on the agenda. |
| 58 | + * [rob] Can't users already clear shortcuts by calling the commands.update() API? |
| 59 | + * [timothy] Firefox does not support the commands API yet, but would be supportive. |
| 60 | + * [carlos] Confirmed that MDN says you can clear with an empty string. |
| 61 | + * [rob] Only Firefox supports an API to change shortcuts via an API, Chrome and Safari do not. |
| 62 | + * [carlos] Benefit of this would be that you could clear without having to set it to something else. |
| 63 | + * [rob] You'd like to clear when a user explicitly clears through settings, correct? How would a user know about this? |
| 64 | + * [carlos] Sounds surprising for users. |
| 65 | + * [rob] Any opinions from Google? Oliver is not here. |
| 66 | + * [tim] We don't have an API for setting them. It's only through manifest keys. |
| 67 | + * [rob] What does “clear” mean? Reset to manifest values? Clear entirely? Would like to have clarity on intent. Using `commands.update` would make this clear. |
| 68 | + * [carlos] With a dedicated `commands.clear` one could reset it to the manifest defined version. This has a library benefit. |
| 69 | + * [timothy] Decent argument for not having to get the manifest to re-set to manifest values. |
| 70 | + * [rob] `commands.reset()` re-sets to manifest value in Firefox. Broader issue of what “clear” means in extensions APIs. This topic comes up frequently. |
| 71 | + * [andrea] How do we distinguish between clearing the binding and reverting to the default. |
| 72 | + * [timothy] null would set to default, empty string would disable the shortcut. |
| 73 | + * [andrea] Having a clear method is probably more explicit. |
| 74 | + * [rob] Neutral on this. No opposition, either. |
| 75 | + * [andrea] Personally I think it's confusing to have empty string/null behavior. I'd prefer an explicit clear method. |
| 76 | + * [rob] If there are other vendors interested in implementing `commands.clear()`, I wouldn't mind implementing it in Firefox either. |
| 77 | + |
| 78 | +[Issue 306](https://github.com/w3c/webextensions/issues/306): scripting.InjectionTarget.workers property to inject WorkerScope(s) |
| 79 | + |
| 80 | + * [kiara] Carlos suggested this as it would help in situations where workers are being used for fingerprinting. |
| 81 | + * [rob] injectionTarget is mostly useful for `scripting.executeScript`. I wonder why it's not part of the declarative APIs. |
| 82 | + * [kiara] Agree that it seems useful for both. |
| 83 | + * [carlos] We have a related issue for registerContentScripts ([issue 103](https://github.com/w3c/webextensions/issues/103)). |
| 84 | + * [kiara] Seems like a reasonable request. Don't know if this would be a high priority issue for us. |
| 85 | + * [rob] Would be a substantial effort to support. Would need to implement scheduling of off-main thread scripts. Open to considering. If running in workers, we'd need some kind of isolated world, which would be entirely new in worker contexts for all browsers. This sounds like a nice feature, but it is unlikely that we'd find time to implement this. |
| 86 | + * [tim] I echo everything Rob said. |
| 87 | + * [andrea] Agreed. |
| 88 | + * [kiara] I'll update the issue's labels. |
| 89 | + |
| 90 | +[Issue 94](https://github.com/w3c/webextensions/issues/94): Support for wildcards in externally_connectable.matches |
| 91 | + |
| 92 | + * [kiara] A request to allow wildcards in `externally_connectable.matches` |
| 93 | + * [rob] Didn't we have this in the draft spec? |
| 94 | + * [PR 873](https://github.com/w3c/webextensions/pull/873): Add specification for externally_connectable. |
| 95 | + * [kiara] Haven't merged the update yet. Is externally_connectable in the pipeline on Firefox? |
| 96 | + * [rob] I think I wanted to implement it at some point, but many other competing priorities. No active effort to implement. |
| 97 | + |
| 98 | +[Issue 991](https://github.com/w3c/webextensions/issues/991): Add ability to disable extension on specific sites with MV3 |
| 99 | + |
| 100 | + * [kiara] I think this is more adding support for a UI in supporting browsers. Users are able to have per-site control/access in Safari today. |
| 101 | + * [rob] Mostly a UI issue, which is outside the scope of this group. We're working on related capabilities in Firefox for enterprise policies, which could serve as the basis for implementing user-facing features. We're referring to this as “negative permissions”: |
| 102 | + * https://bugzilla.mozilla.org/show_bug.cgi?id=1745823 |
| 103 | + * [tim] We support this globally, but not for individual extensions. Just need UI for this |
| 104 | + * [andrea] Definitely came up before, this is desirable. |
| 105 | + * [rob] I'll close the issue since this is a UI request and not an API. |
| 106 | + * [kiara] Do we have an issue for specifying negative host permissions? |
| 107 | + * [carlos] https://github.com/w3c/webextensions/issues/123 (“Proposal: add disallow_host_permissions”) |
| 108 | + * [timothy] I think its still important to have the manifest key. Allows the extension to explicitly opt itself out of sites the developer knows it doesn't work on. |
| 109 | + * [rob] No objection against the manifest key, especially if the internals are already there. |
| 110 | + * [casey] As a developer we would love that. E.g. declaring not running on healthcare sites. |
| 111 | + * [rob] If an example specified `example.com` in `disallowed_host_permissions`, would the user be able to override that? |
| 112 | + * [andrea] Would runtime APIs be out of scope? |
| 113 | + * [kiara] I think this is in line with 123. |
| 114 | + * [simeon] Worried about potential abuse if extensions can remove what was set in the manifest file. |
| 115 | + * [rob] This could be additive: the declarations in the manifest file would be static and not removable, the extension could still add more disabled hosts at runtime. |
| 116 | + * [carlos] You can already remove host permissions via the runtime API. Having a negative version of that doesn't seem unreasonable. |
| 117 | + * [krzysztof] May be missing the point of this. If the list of domains is known, the developer already has the power to ignore these events. |
| 118 | + * [carlos] if you have disallowed host permissions in the manifest, you potentially reduce the attack surface. |
| 119 | + |
| 120 | +[PR 975](https://github.com/w3c/webextensions/pull/975): Update runtime.onInvalidated with unload reason and isolated world restriction |
| 121 | + |
| 122 | + * [kiara] Approvals form all browser vendors. Looks like this just needs a merge. |
| 123 | + * [rob] Just merged. |
| 124 | + |
| 125 | +[PR 989](https://github.com/w3c/webextensions/pull/989): Proposal: Asynchronous Listener Registration |
| 126 | + |
| 127 | + * [andrea] We currently require that extensions register event listeners synchronously, but not all developers follow this. We want to introduce an API that allows the extension to delay the dispatch of events until registration is complete. One of the goals was to provide more granular control over registration of listeners. Rob reviewed the PR and asked about controlling persistence of listeners. Would like to focus on async listener registration if possible. |
| 128 | + * [rob] We have some discussions on toggling listeners, but they have stalled. E.g. https://github.com/w3c/webextensions/issues/501. |
| 129 | + * [andrea] I think it would make the most sense if each listener had an option that allowed it to specify it wasn't to persist. |
| 130 | + * [andrea] I also updated the proposed name based on your feedback, from `runtime.markInitializationComplete()` to `runtime.markListenersRegistrationComplete()`. |
| 131 | + * [rob] Manifest key would also be renamed, right? |
| 132 | + * [andrea] Yes. I think we could call it “async_registration” right now. |
| 133 | + * [rob] That's a bit vague. Can bikeshed later. Would like the name to be more clear on what exactly this flag does. |
| 134 | + * [carlos] Potential backwards compatibility – do we know if all browsers allow setting additional keys in the background object? |
| 135 | + * [rob] Good question. In general for unknown keys I think we've said it shouldn't affect things. I don't think Chrome allows it. Firefox doesn't fail for unknown properties in the background key, just prints a warning. |
| 136 | + * [kiara] In Safari we don't fail on unsupported keys. |
| 137 | + * [carlos] Tested unknown background property in Chrome, Firefox, Safari and Orion. All load it fine without error. |
| 138 | + * [simeon] As I recall from previous discussions we aligned that top level unknown keys wouldn't error, but sub-keys were undefined. I believe Chrome errors on unknown sub-keys. |
| 139 | + * [rob] Not sure if already addressed, but I also asked about the API availability since this is intended to be used in background contexts only. |
| 140 | + * [andrea] I've updated the proposal. We only want this for the background context. |
| 141 | + * [rob] I'll review the updated proposal and if there are no other issues sign off. Bikeshed on names? |
| 142 | + * [andrea] “async_listener_registration” would may be more clear |
| 143 | + * [krzysztof] await_listeners? State the intention. |
| 144 | + * [andrea] Doesn't make clear that you have to call the API after. I think “registration” should be in the name |
| 145 | + * [rob] `delayed_listener_registration_finalization`? Maybe a bit too long. Want it to be obvious that this queues events. We can follow up on the PR with some async discussion. |
| 146 | + * [kiara] I'll take a look at the PR as well. Understand the use case and think this seems reasonable. |
| 147 | + |
| 148 | +[Issue 994](https://github.com/w3c/webextensions/issues/994): Inconsistency: `commands._execute_action.description` |
| 149 | + |
| 150 | + * [kiara] Basically a bunch of inconsistencies with command execution. |
| 151 | + * [carlos] (rehashes the issue) Main one is Firefox requires this addition in the manifest to specify an action keyword. In Safari and Chrome a shortcut for the extension button is always shown, even without the extension declaring so. (…) Chrome does not currently allow overriding the description, even if other browsers do. |
| 152 | + * [kiara] For the second one where we use the extension name, I think its reasonable to use text similar to what Chrome and Firefox do. |
| 153 | + * [timothy] I think in some places we use short name too. |
| 154 | + * [david] I think one of the motivations is that we want to make menu items unique, not just have a bunch of “activate extension” labels. |
| 155 | + * [rob] In Firefox I believe these are sub-items for a given extension, so from context it's clear what they are. I think out of the full list 2, 3 and 4 are browser specific issues. |
| 156 | + * [rob] Carlos, do you know if there's any demand for developers or users to auto-generate shortcuts for the action? |
| 157 | + * [carlos] I include it in all my extensions. Which is presumably based on historic user demand. |
| 158 | + * [carlos] In browsers which have one big list of extensions, automatically allowing customization can result in an overwhelming list. |
| 159 | + * [kiara] That would be browser-specific. In Safari we show them for one extension. |
| 160 | + * [rob] Could give it less priority for extensions that don't declare a shortcut. Personally neutral on this, on the verge of positive. |
| 161 | + * [kiara] I'll collect Safari bugs for the issues identified. |
| 162 | + |
| 163 | +Meta discussion: Should proposals require an issue next to the PR? |
| 164 | + |
| 165 | + * [kiara] Good point to ask for new proposals, do we want to have issues associated with them before there's a new proposal? The issue for async listeners didn't have an issue first. |
| 166 | + * [carlos] I believe historically we've required that proposals have a related issue. |
| 167 | + * [rob] Not sure if we required that, but out process has been pretty lax. An issue would be nice. |
| 168 | + * [andrea] Is the intent to separate discussions of the merrit of the issue and the specific proposal? |
| 169 | + * [kiara] Yes. Discussion of the merits of the issue. Nice to have an issue to work through the specific approach. |
| 170 | + * [andrea] Happy to retroactively create an issue. |
| 171 | + * [kiara] Don't think that's necessary, but would be good in general to have an issue first. |
| 172 | + * [rob] I have two experiences that are opposite. Recently reviewed a proposal and issue where discussion happened on both, which is difficult to follow. More frequently, an initial proposal submitted with no issue, then later a refinement of the proposal with no link back to motivating discussion. Having an issue would make it easier to continue the conversation on the relevant issue. |
| 173 | + * [simeon] Mostly echoing what others have said. Would like to |
| 174 | + * [rob] We should update the proposal process doc if we require it. |
| 175 | + * [simeon] I'll update that. Created https://github.com/w3c/webextensions/issues/996 to track. |
| 176 | + |
| 177 | +[Issue 995](https://github.com/w3c/webextensions/issues/995): Allow extensions to query the list of languages it supports (ie, i18n.getAvailableLanguages()) |
| 178 | + |
| 179 | + * [carlos] (...). Oliver had concerns but I think that these have been resolved. |
| 180 | + * [kiara] Would not be opposed to it. |
| 181 | + * [andrea] What was Oliver's point? |
| 182 | + * [kiara] Extensions can have a build step to get this information without requiring the browser to provide this. |
| 183 | + * [timothy] See no harm in adding it. Big proponent of not using build tools. |
| 184 | + * [rob] I didn't really see the use case, but if there's another sponsoring browser I'd be open to accepting. |
| 185 | + |
| 186 | +Update on working group (WG): |
| 187 | + |
| 188 | + * [simeon] We have gotten the minimal required number of approvals. Our W3C contact (mike, sideshowshadowbarker) will take it to the internal group for final approvals. Tentatively scheduled to formally create the Working Group this month (May). Tentatively the Working Group meetings are to be scheduled in the other week when there are no CG meetings. WG meetings are closed meetings (to members only), CG meetings continue to be public. |
| 189 | + |
| 190 | +The next meeting will be on [Thursday, May 21st, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6a0f9c80,384). |
0 commit comments