|
| 1 | +# WECG Meetings 2025, Public Notes, Aug 28 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=68b0ed80,384 |
| 7 | +Call-in details: [WebExtensions CG, 28th August 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20250828T080000/) |
| 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 #865](https://github.com/w3c/webextensions/issues/865), [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 863](https://github.com/w3c/webextensions/issues/863): Proposal: add chrome.tabs.captureTab() API to Chromium |
| 20 | + * [Issue 861](https://github.com/w3c/webextensions/issues/861): Enhancement request - Expand the Tab Groups API to include some info about Closed Tab Groups |
| 21 | + * **Timely issues** (10 minutes) |
| 22 | + * [Issue 762 comment](https://github.com/w3c/webextensions/issues/762#issuecomment-3200174155): DNR: Add excludedTopFrameDomains (and topFrameDomains) ([@kzar](https://github.com/kzar)) |
| 23 | + * "I have a [draft Chromium PR](https://chromium-review.googlesource.com/c/chromium/src/+/6851057) for that, and the Chromium team want to make sure others browser vendors are happy before we go ahead." |
| 24 | + * **Check-in on existing issues** (20 minutes) |
| 25 | + * [Issue 799](https://github.com/w3c/webextensions/pull/799): Add browser.permissions.canAccess() proposal |
| 26 | + |
| 27 | + |
| 28 | +## Attendees (sign yourself in) |
| 29 | + |
| 30 | + 1. Rob Wu (Mozilla) |
| 31 | + 2. David Johnson (Apple) |
| 32 | + 3. Lena Cohen (EFF, Privacy Badger) |
| 33 | + 4. Oliver Dunk (Google) |
| 34 | + 5. Simeon Vincent (Mozilla) |
| 35 | + 6. Tomislav Jovanovic (Mozilla) |
| 36 | + 7. Mukul Purohit (Microsoft) |
| 37 | + 8. Carlos Jeurissen (Jeurissen Apps) |
| 38 | + |
| 39 | + |
| 40 | +## Meeting notes |
| 41 | + |
| 42 | +[Issue 863](https://github.com/w3c/webextensions/issues/863): Proposal: add chrome.tabs.captureTab() API to Chromium |
| 43 | + |
| 44 | + * [simeon] Rob, do you know anything about the considerations behind why Mozilla decided to add support for captureTab? |
| 45 | + * [rob] captureVisibleTab only captures the visible viewport, and requires host permissions to scroll down in the tab. https://bugzilla.mozilla.org/show_bug.cgi?id=1427463. |
| 46 | + * [simeon] captureVisibleTab captures the visible tab of a window, captureTab can capture any tab, including background tabs. Concerning? |
| 47 | + * [oliver] captureTab requires `<all_urls>`. Seems like a reasonable limitation. |
| 48 | + * [simeon] I might just be dissatisfied with `<all_urls>` as a general capability restriction. |
| 49 | + * [oliver] Can get issues where screenshots are not properly aligned. |
| 50 | + * [tomislav] I think we just ask for a screenshot as currently scrolled. Won't be totally correct if things aren't scrolled. |
| 51 | + * [oliver] If all browsers implement this with a best effort basis, is that acceptable, or are there behaviors we want to align on? |
| 52 | + * [simeon] At the high level, if we are aligned on the principles, that sounds good? |
| 53 | + * [rob] Things rendered in the background or tabs that have been discarded, we don’t support capturing them. We could only provide guarantees for content that is visible. Everything else is done on a best effort basis. If every tab is a million pixels tall, we couldn't realistically keep that available in memory. |
| 54 | + * [oliver] If there are guarantees on captureTab limiting to the currently active tab, would it make sense to expose that to the captureVisibleTab method instead? |
| 55 | + * [tomislav] We (Firefox) already have that. Discussed some of the subtlties here with a chromium person in a captureVisibleTab issue https://github.com/w3c/webextensions/issues/855 |
| 56 | + * [rob] I will need to read the design doc before aligning on a plan. This patch was contributed to Chromium by Igalia. Oliver, do you know what the motivations for this issue & design doc are? |
| 57 | + * [oliver] I don't have additional context. |
| 58 | + * [rob] Suggest we follow up async. |
| 59 | + * [david] Either approach makes sense; captureVisibleTab requires each tab to become focused which may limit use cases (eg: exposé of all tabs on a new tab page) |
| 60 | + * [simeon] Rob, do you know how we handle discarded tabs? |
| 61 | + * [rob] Not sure. May return nothing or throw an error. Either makes sense. I think that it makes more sense to not eagerly un-discard discarded tabs. |
| 62 | + * [tomislav] We try to not wake up discarded tabs when extensions do normal stuff. We mostly deal with the opposite problem: loading too much data as a result of an API call doing more than expected. |
| 63 | + |
| 64 | +[Issue 861](https://github.com/w3c/webextensions/issues/861): Enhancement request - Expand the Tab Groups API to include some info about Closed Tab Groups |
| 65 | + |
| 66 | + * [rob] Carry-over from last meeting; revisiting because Google was absent last time. |
| 67 | + * [simeon] Issue spawned from a thread in Mozilla's Discourse. A request to allow extensions to integrate better with tab groups. |
| 68 | + * [oliver] Not sure if this is the right API to expose the concept in this way. Beyond that I haven't heard much appetite around catching up the API to Chrome's capabilities, so I can't speak to that. Open to looking at a proposal if someone else champions it. |
| 69 | + * [rob] On the Firefox side I don't think we're going to proactively pursue this right now. Open to community contributions on use cases and API proposals. |
| 70 | + * [david] Safari doesn't currently support the tab groups API. Our closest concept is quite different from how other browsers have approached this. |
| 71 | + * [mukul] No additional thoughts to add. |
| 72 | + |
| 73 | +[Issue 762 comment](https://github.com/w3c/webextensions/issues/762#issuecomment-3200174155): DNR: Add excludedTopFrameDomains (and topFrameDomains) ([@kzar](https://github.com/kzar)) |
| 74 | + |
| 75 | + * [kzar async] I have a [draft Chromium PR](https://chromium-review.googlesource.com/c/chromium/src/+/6851057) for that, and the Chromium team want to make sure others browser vendors are happy before we go ahead." |
| 76 | + * [rob] The proposal introduces a `declarativeNetRequest.RuleConditionKeys` object listing fixed keys and mappings to supported keys. |
| 77 | + * [oliver] Recently landed a CL to match top frames in a DNR rule. This essentially adds a big dictionary in the DNR namespace that can be used to check if a given rule type is supported. |
| 78 | + * [rob] A year or two ago Chrome added support for matching response headers via a new key, and the common mechanism to feature detect (call and catch errors) was not working, due to the flag controlling availability being out of sync with the API bindings. Is that handled correctly by this? Would this be implemented behind a flag and the feature hidden when not enabled? |
| 79 | + * [oliver] I believe so. |
| 80 | + * [rob] If it is already possible to have limited feature detection by calling and catching errors, then what does this proposal add? |
| 81 | + * [oliver] As I recall when we looked into this in the past some browsers had different behavior when a condition wasn't supported. |
| 82 | + * [david] In Safari, we do a best effort to compile the rules. Depending on the fatality of the error, we may fail the rule list. |
| 83 | + * [alexei] My impression was that rules silently fail. That is, they fail to be registered but there's no feedback of that failure. |
| 84 | + * [rob] Right, that matches my impression of Safari: it accepts unrecognized property names without throwing, whereas Chrome and Firefox throw. It would be nice if there was a way to declare that a ruleset should only be compiled if certain functionality were supported, which also helps with DNR feature adoption in static rules, and not just dynamic/session rules. |
| 85 | + * [simeon] Effectively suggestion a CSS-style @supports rule, right? |
| 86 | + * [rob] Yes. We've discussed similar ideas in a past face to face meeting. |
| 87 | + * [carlos] Would it not make sense to let Safari throw on unknown props when setting dynamic rules? |
| 88 | + * [oliver] Just checked in chrome and we throw an error when there's an unexpected condition on a rule. |
| 89 | + * [rob] I'm not sure why this specific implementation has a CL. May need to read more to get additional context. |
| 90 | + * [alexei] Are you saying you don't see the point of feature detection? |
| 91 | + * [rob] I do, just not this specific approach. |
| 92 | + * [alexei] What should extensions do to make use of topDomains and excludedTopDomains when used in browsers that don't support it? |
| 93 | + * [rob] In Firefox and Chrome, extensions can create session rules for this and the compilation will fail if they're not supported, at least in theory. I see the limitations of this approach, in browser bugs and different behavior in Safari. |
| 94 | + * [alexei] Also a much more complex approach. Privacy Badger debounces updates in order to apply them all at the same time. Our approach means there's no good way to retry. We can detect that it fails, but it would be difficult for us to fix the rules and retry them, but it would be very easy for us to feature detect using this dictionary. That's straightforward, but catching and handling errors is complicated. |
| 95 | + * [rob] Do you require it to be synchronous? |
| 96 | + * [alexei] Sync would be preferable, but async is acceptable |
| 97 | + * [rob] A `isSupported` method would allow us to expand over time. I'm willing to consider a synchronous API if there is a cross-browser consensus. |
| 98 | + * [tomislav] Is Alexei's proposal in line with how we handle enums for supported things in other APIs? |
| 99 | + * [rob] We don't have precedent for this. We have keys for enum values, but not for property names. Currently we only throw synchronously if a property isn't recognized. |
| 100 | + * [oliver] Two concerns with `isSupported`. We discussed it before. Doesn't feel as ergonomic. Would need to construct a dummy object for the request. It would be easier to check a key to see if something is supported. |
| 101 | + * [oliver] I could easily see how we'd add a new enum for each other property we want to check the support of. The current proposal has a patch in Chromium, if we don't pursue this I don't know if we would have the capability for an alternative method. |
| 102 | + * [rob] kzar is a contributor. If we agreed on a specific direction, e.g. an `isSupported` method, then they could handle that implementation, assuming that they are motivated by having the functionality at all rather than a specific API shape. |
| 103 | + * [oliver] Don't want to assume. They might not be interested in taking on that additional work. |
| 104 | + * [simeon] Okay, going back it sounds like the answer to the question that motivated this discussion, “are all browser vendors okay with this”, is no, but we don't have a specific preferred solution, correct? |
| 105 | + * [oliver] Could suggest the isSupported approach and see if kzar is open to working on that. |
| 106 | + * [tom] in Firefox most things are lazily initialized, so it wouldn't be populated until the extension attempts to access it. |
| 107 | + * [david] I'll discuss this internally. |
| 108 | + * [rob] Let's revisit this topic later. |
| 109 | + * [carlos] FYI: precedent in web platform API, `navigator.canShare` method that tells whether an API call with the given properties would succeed: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/canShare |
| 110 | + |
| 111 | +[Issue 799](https://github.com/w3c/webextensions/pull/799): Add browser.permissions.canAccess() proposal |
| 112 | + |
| 113 | + * Action: Discuss if we want to merge fetch access and contentscript access before implementing permissions.canAccess? |
| 114 | + * [carlos] In Chrome when you open an action popup with activeTab, it gives you the ability to inject content scripts in the active tab. It also grants you the ability to perform fetch() requests on the domain in Chrome. This is different in Firefox and Safari. Would be nice if that capability was also available in the other browsers. Would like to align on this if possible. |
| 115 | + * [tomislav] Generally I'm in favor of activeTab granting host permissions (fetch access, webRequest, etc). |
| 116 | + * [rob] This discussion started with the question of whether content script access and fetch access should be treated differently. It sounds like your answer is no? |
| 117 | + * [tom] I'm not sure. I recall Devlin mentioning an idea about limiting access in specific situations, but I don't recall the details. |
| 118 | + * [rob] Anyone browser vendors have thoughts on how this should be handled? |
| 119 | + * [carlos] If it's complicated and we don't expect this to be unified any time soon, it's probably best to have them be separate concepts for now. |
| 120 | + * [oliver] Very easy to set them both to true if we do align. |
| 121 | + * [rob] We could start with just one (e.g. host access) and introduce a new property later if we need to provide additional introspection. |
| 122 | + * [carlos] Would be in favor of having specific key names. |
| 123 | + * [oliver] I think the motivation here was to remove ambiguity. Having a key name that kind of covers what you want doesn't align with that goal. |
| 124 | + * [tomislav] We already have other use cases that aren't mentioned, like captureVisibleTab. That's another kind of “can access” use case where we may need additional special casing in the future. |
| 125 | + * [rob] I agree with that. |
| 126 | + * [carlos] I'd be in favor of not having a generic property in order to give developers more specific insight into what kind of access they have. |
| 127 | + * [simeon] My mental model for activeTab is that it is literally the same having a host permission for the tab's origin, but session-bound. I don't know if that's exactly the right set of tradeoffs, but I see a big advantage to this approach in that it greatly simplifies the ability of a new developer to understand what it does and how it works. Predictability and explicability are two of my major concerns with API design in general. |
| 128 | + * [tomislav] Agree, but to throw a wrench in that, should activeTab grant the extension access to the child frames? Should the extension's content scripts run in those frames? |
| 129 | + * [simeon] In this model, no. I fully recognize that's an imperfect tradeoff. |
| 130 | + * [rob] Time check, we're at -1 minutes. |
| 131 | + * [simeon] We should definitely continue to discuss how activeTab works. |
| 132 | + |
| 133 | +The next meeting will be on [Thursday, September 11th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68c36280,384). |
0 commit comments