|
| 1 | +# WECG Meetings 2025, Public Notes, Dec 4 |
| 2 | + |
| 3 | + * Chair: Kiara Rose |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PST = https://everytimezone.com/?t=69322080,3c0 |
| 7 | +Call-in details: [WebExtensions CG, 4th December 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20251204T080000/) |
| 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 #914](https://github.com/w3c/webextensions/issues/914), [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 915](https://github.com/w3c/webextensions/issues/915): Inconsistency: `tabs.query` behavior for permissions granted by `content_scripts.matches` |
| 20 | + * [Issue 916](https://github.com/w3c/webextensions/issues/916): Sidepanel API: Behavioral inconsistencies with Chrome and Edge implementations |
| 21 | + * [Issue 917](https://github.com/w3c/webextensions/issues/917): Proposal: Add `management.readOnly` permission for read-only access to management API |
| 22 | + * [Issue 918](https://github.com/w3c/webextensions/issues/918): Grant time-based user activation from extension events that grant a user gesture |
| 23 | + * [Issue 919](https://github.com/w3c/webextensions/issues/919): Should user gestures be curried between contexts? |
| 24 | + * [Issue 920](https://github.com/w3c/webextensions/issues/920): Should extension APIs consume user activation? |
| 25 | + * **Timely issues** (10 minutes) |
| 26 | + * [PR 802](https://github.com/w3c/webextensions/pull/802): Add proposal for `topFrameMatches` and `excludeTopFrameMatches` |
| 27 | + * [PR 885](https://github.com/w3c/webextensions/pull/885): Correct `iconVariants` and `colorSchemes` casing. Add `NotificationOptions.iconVariants` |
| 28 | + * **Check-in on existing issues** (20 minutes) |
| 29 | + * [Issue 449](https://github.com/w3c/webextensions/issues/449): Provide way of handling unsupported DNR rule |
| 30 | + |
| 31 | + |
| 32 | +## Attendees (sign yourself in) |
| 33 | + |
| 34 | + 1. Giorgio Maone (NoScript, Tor) |
| 35 | + 2. Rob Wu (Mozilla) |
| 36 | + 3. Sohail Rajdev (Microsoft) |
| 37 | + 4. Simeon Vincent (Mozilla) |
| 38 | + 5. Tomislav Jovanovic (Mozilla) |
| 39 | + 6. Patrick Kettner (Google Chrome) |
| 40 | + 7. Kiara Rose (Apple) |
| 41 | + 8. Carlos Jeurissen (Jeurissen Apps) |
| 42 | + 9. Dave Vandyke (DuckDuckGo) |
| 43 | + 10. Timothy Hatcher (Apple) |
| 44 | + 11. David Johnson (Apple) |
| 45 | + 12. Mukul Purohit (Microsoft) |
| 46 | + 13. Jordan Spivack (Capital One) |
| 47 | + |
| 48 | + |
| 49 | +## Meeting notes |
| 50 | + |
| 51 | +TPAC meeting notes |
| 52 | + |
| 53 | + * [rob] TPAC 2025 ([issue 843](https://github.com/w3c/webextensions/issues/843)) meeting notes are pending review and publication at https://github.com/w3c/webextensions/pull/923. |
| 54 | + |
| 55 | +[Issue 915](https://github.com/w3c/webextensions/issues/915): Inconsistency: `tabs.query` behavior for permissions granted by `content_scripts.matches` |
| 56 | + |
| 57 | + * [kiara] This issue was filed by someone from Chromium. |
| 58 | + * [patrick] No action item for today. |
| 59 | + * [kiara] Can follow up next week. |
| 60 | + |
| 61 | +[Issue 916](https://github.com/w3c/webextensions/issues/916): Sidepanel API: Behavioral inconsistencies with Chrome and Edge implementations |
| 62 | + |
| 63 | + * [kiara] Whether side panel should stay open. |
| 64 | + * [sohail] Not sure if by design or a bug, I'll take a look. |
| 65 | + |
| 66 | +[Issue 917](https://github.com/w3c/webextensions/issues/917): Proposal: Add `management.readOnly` permission for read-only access to management API |
| 67 | + |
| 68 | + * [kiara] Request for `management.readOnly` permission. We do not have a `management` API in Safari, but it sounds reasonable. Any input from Firefox? |
| 69 | + * [tomislav] This was discussed during TPAC. Sounds reasonable. `management.getSelf()` is already available, this is just for getting the information for other extensions, right? |
| 70 | + * [patrick] Yes. |
| 71 | + * [patrick] Another idea is to establish a pattern for other APIs with similar read-only capabilities. |
| 72 | + * [rob] I'm supportive of the `.readOnly` suffix as a pattern for read-only API permissions. |
| 73 | + * [tomislav] Same. |
| 74 | + * [dave] I wonder if extensions could misuse the ability to check which other extensions are installed. E.g. one extension telling the user to uninstall all their ad blockers or something. |
| 75 | + * [patrick] Yes, it is the purpose of the API to expose that. Seen in the past that extensions tried to block screenshot extensions. |
| 76 | + * [rob] The permission would still have a warning, just a less scary one, right? |
| 77 | + * [patrick] Yes. |
| 78 | + * [sohail] How would events be exposed to this API when an extension has the read only API? |
| 79 | + * [patrick] Events would still be dispatched, but the extension would not be able to change things related to other extensions. |
| 80 | + * [tomislav] If we don't expose events, extensions could still gather data via polling, which isn't a pattern we want to encourage. |
| 81 | + * [dave] What is the purpose of allowing one extension to know which other one exists? E.g. I understand that it would be nice for a content blocker to detect other content blockers to detect potential conflicts. I see downsides too, e.g. don't want the Amazon extension to detect Bitwarden. |
| 82 | + * [patrick] Doesn't change exposed information; the management API can already do that. The purpose of this is to reduce the API capabilities for those that only need read-only access. Content blockers are indeed an example of use cases that have asked for this. |
| 83 | + * [timothy] Dave's concerns are the same reason why we have not implemented the `management` API in Safari. I don't expect Safari to ever allow an extension to see extensions other than those from the same developer. |
| 84 | + * [patrick] Seen enterprise use cases that want to control installed extensions. |
| 85 | + * [simeon] I imagine Safari to have other mechanisms to support that use case. |
| 86 | + * [timothy] We do have other ways to allow administrators to force disable extensions through device management solutions. |
| 87 | + * [simeon] Might be worth considering how read-only would apply to host permissions. |
| 88 | + * [tomislav] For the moment we should exclude them from this concept. |
| 89 | + |
| 90 | +[Issue 918](https://github.com/w3c/webextensions/issues/918): Grant time-based user activation from extension events that grant a user gesture |
| 91 | + |
| 92 | + * [kiara] This and next two issues are related and discussed at TPAC. |
| 93 | + * [kiara] Considering time-based user interaction. Safari is supportive. |
| 94 | + * [rob] Also supportive. We discussed this at TPAC and would like to improve this area. |
| 95 | + * [rob] Chrome is also supportive, judging by the labels on the issue. |
| 96 | + |
| 97 | +[Issue 919](https://github.com/w3c/webextensions/issues/919): Should user gestures be curried between contexts? |
| 98 | + |
| 99 | + * [kiara] Firefox, do you have thoughts on this? |
| 100 | + * [rob] Hesitant. Currying has some concerning potential abuses. I would like to see a proposal. |
| 101 | + * [tomislav] Two cases: Content script to background page, extension page to background page. One of them is an extension context, the other a page context, we may want to treat them differently. I may be in favor of extension-to-extension contexts because that is less prone to abuse. Extension could injects its own iframe in the web page, and use messaging from within that iframe to the background. |
| 102 | + * [rob] Does Safari have any concerns with currying? |
| 103 | + * [kiara] Currently supportive. |
| 104 | + * [rob] Any hesitations around relaying gestures from content scripts to extensions? Content scripts make it very easy to capture a user gesture and degrades the quality of the signal with respect to user intent. |
| 105 | + * [timothy] Valid concern. Worth being more hesitant in that direction. We currently have `permissions.request` behind a user gesture. Popping up an alert may be annoying. |
| 106 | + * [rob] At TPAC we discussed propagating user interaction from an extension API event in the background to a content script. I am supportive of that with an explicit opt-in signal. |
| 107 | + * [timothy] Open to an explicit signal. |
| 108 | + * [rob] In that case it would be an explicit signal. Does that remove your concern about different behaviors depending on direction? |
| 109 | + * [timothy] Don't think that it is worth making a difference based on direction. |
| 110 | + * [rob] What is Google's position? |
| 111 | + * [kiara] Chrome already does currying. |
| 112 | + * [tomislav] I remember Devlin being concerned about some aspect of the current implementation. |
| 113 | + * (this discussion continues in the next topic on user activation) |
| 114 | + |
| 115 | +[Issue 920](https://github.com/w3c/webextensions/issues/920): Should extension APIs consume user activation? |
| 116 | + |
| 117 | + * [kiara] Should extension APIs consume user activation? |
| 118 | + * [simeon] In short yes, but may involve complexity because with currying there is not a single place where you would consume the activation. |
| 119 | + * [tomislav] In order to do this, this would require an explicit signal when currying messages. What would consume it? Being explicit about what consumes it would make it easier to document and understand what's happening. |
| 120 | + * [rob] Currying is a separate discussion. On the issue Oliver expressed that Chrome wants to consume user activation, for example when `downloads.open()` is called. I am also supportive of that. |
| 121 | + * [tomislav] Yes, it makes sense for methods that require a gesture to consume it. |
| 122 | + * [rob] Is Safari also supportive of consuming the user activation when `permissions.request()` is called (which is the only API requiring a user gesture in your implementation)? |
| 123 | + * [timothy] Yes. |
| 124 | + * [simeon] Only concern I have is that there may be existing use cases that require an activation that are called in the same turn of the event loop. Perhaps we could add telemetry to help understand current usage? |
| 125 | + * [sohail] Can implementing this break existing extensions? |
| 126 | + * [simeon] I believe so, that's why I think we may want to add some telemetry here and assess potential impact. |
| 127 | + * [tomislav] Does Chrome have many more methods that would consume? We currently have around half a dozen or so. |
| 128 | + * [patrick] Don't know for sure. I feel like we have more, but not clear offhand. |
| 129 | + * [simeon] Thoughts on whether we should add telemetry? |
| 130 | + * [tomislav] I think we have too few for this to be a practical problem. |
| 131 | + * [simeon] What about something like initiating multiple downloads? |
| 132 | + * [tomislav] Hadn't considered. Good point. |
| 133 | + * [rob] I expect `permissions.request()` will be the most common consumer. Since Chrome does currying, I think that they can collect the most meaningful telemetry to measure the prevalence of currying and the reliance on that. |
| 134 | + * [patrick] I'm sure that we wanted it; don't know if we can prioritize it. Other examples are offscreen documents where web APIs require user activation. |
| 135 | + * [simeon] I think one of the most concrete use cases (at least for my own use) is clipboard interaction. In Chrome the extension needs to fall back to the old DOM clipboard APIs. |
| 136 | + * <discussion resumed at the end of the meeting> |
| 137 | + * [simeon] We potentially have a matrix of options . |
| 138 | + * [carlos] There's also the concept of a sticky user activation. |
| 139 | + * [tomislav] I don't know if we have any method that would require an activation but not consume it. Cases where that might apply, like `action.openPopup()`, are moving away from requiring it in the first place. |
| 140 | + * [rob] I don't think consumption is contentious. The bigger question is how we should handle currying. `permissions.request()` seems like a case where we'd want to take proactive action to limit the ability to call it. May want to introduce a manifest key to allow extensions to curry from a content script to a background if we were to introduce this functionality. Also, I'd like to see data on how useful this would be. Not clear the benefit outweighs the abuse potential. |
| 141 | + * [simeon] Extensions can inject an iframe that calls `permissions.request()` without the need for currying. While I feel this addresses many potential uses of currying, I want to recognize that this is an odd design pattern for a typical web developer. I don't expect the average extension dev to realize they can do something like this. |
| 142 | + * [rob] Until Chrome implemented site isolation (about a decade ago), extension APIs were restricted in iframes. Nowadays Chrome extensions can indeed call extension APIs from extension frames. In Firefox we still restrict the API availability in extension frames though. |
| 143 | + |
| 144 | +[PR 802](https://github.com/w3c/webextensions/pull/802): Add proposal for `topFrameMatches` and `excludeTopFrameMatches` |
| 145 | + |
| 146 | + * [rob] This proposal is about implementing a feature for [issue 763](https://github.com/w3c/webextensions/issues/763). We were all generally supportive, now we just need to review the details. |
| 147 | + * [kiara] I will also add myself as a reviewer. |
| 148 | + |
| 149 | +[PR 885](https://github.com/w3c/webextensions/pull/885): Correct `iconVariants` and `colorSchemes` casing. Add `NotificationOptions.iconVariants` |
| 150 | + |
| 151 | + * [kiara] Looks like this was merged. Was this also proposed for a previous meeting? |
| 152 | + * [rob] Yes. It was nominated but not discussed, then merged in the meantime. |
| 153 | + |
| 154 | +[Issue 449](https://github.com/w3c/webextensions/issues/449): Provide way of handling unsupported DNR rule |
| 155 | + |
| 156 | + * [dave] Working on adding new rule conditions to DNR. `topDomains`/`excludedTopDomains` in the past. What we did in the past is to tell people to wait for a bit until most users have updated their browsers before using it. For enum types there are objects on the namespace to support feature detection; for dictionaries that does not exist. Need API that let's one know that a rule can be used. But at least for the dictionary case. |
| 157 | + * [rob] I believe this was discussed before. My preference was for a dedicated method to handle this rather than relying on properties, but if my approval is the only blocker to shipping properties, I'm not going to oppose the addition of these properties. For example, `testMatchOutcome()` could be expanded to take a rule to check if a request would match/not match, to enable feature detection in extensions. I have encountered a situation in Chrome where the API namespace showed the availability of a feature, but did not actually enable the feature. A dedicated method can be more reliable than just checking for properties (when Chrome added support for header matching, the properties were available before the feature was actually enabled). |
| 158 | + * [dave] Agree a test method could help. I'd be supportive of a more generic method like this. |
| 159 | + * [kiara] On Safari side, we'd be supportive of an enum. I feel a method based approach would be better, but that's non-blocking. |
| 160 | + * [dave] Method and enum approaches are not necessarily mutually exclusive. |
| 161 | + |
| 162 | +The next meeting will be on [Thursday, December 18th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=69449580,3c0). |
0 commit comments