|
| 1 | +# WECG Meetings 2025, Public Notes, Jul 31 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=688c0380,384 |
| 7 | +Call-in details: [WebExtensions CG, 31st July 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20250731T080000/) |
| 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 #854](https://github.com/w3c/webextensions/issues/854), [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 | + * [Issue 843](https://github.com/w3c/webextensions/issues/843): TPAC registration is open, we have ~12 hours of[ meeting time scheduled](https://github.com/w3c/webextensions/issues/843#issuecomment-3140015582) across Monday and Thursday. |
| 19 | + * **Triage** (15 minutes) |
| 20 | + * [Issue 849](https://github.com/w3c/webextensions/issues/849): Inconsistency: native messaging size limit |
| 21 | + * [Issue 855](https://github.com/w3c/webextensions/issues/855): Proposal: Clarify the scale parameter for tabs.captureVisibleTab |
| 22 | + * [Issue 856](https://github.com/w3c/webextensions/issues/856): Inconsistency: browser.downloads.download API can ignore file name extension if MIME is known type |
| 23 | + * **Timely issues** (0 minutes) |
| 24 | + * N/A |
| 25 | + * **Check-in on existing issues** (20 minutes) |
| 26 | + * [Issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains) ([@lenacohen](https://github.com/lenacohen)) |
| 27 | + * The outstanding comment from Oliver on https://github.com/w3c/webextensions/pull/837 and see if Apple can take a look. |
| 28 | + * **Open discussion** |
| 29 | + * PSA: A German appeals court is considering whether to ban adblockers on the grounds that they are creating derivative works of webpages. |
| 30 | + * [Issue 616](https://github.com/w3c/webextensions/issues/616): Content script injection inconsistencies in the sidePanel |
| 31 | + * DNR / Content Script compatibility with non-tab contexts (such as sidebars) (Maone) |
| 32 | + * [PR 852](https://github.com/w3c/webextensions/pull/852#discussion_r2225631737): WPT update, also quick assertTrue discussion |
| 33 | + * [Issue 116 comment](https://github.com/w3c/webextensions/issues/116#issuecomment-3032442917): Proposal: stop adding `host_permissions` from `content_scripts` |
| 34 | + * [Pull 799 comment](https://github.com/w3c/webextensions/pull/799#discussion_r2080111012): Add `browser.permissions.canAccess()` proposal |
| 35 | + |
| 36 | + |
| 37 | +## Attendees (sign yourself in) |
| 38 | + |
| 39 | + 1. Rob Wu (Mozilla) |
| 40 | + 2. Simeon Vincent (Mozilla) |
| 41 | + 3. Tomislav Jovanovic (Mozilla) |
| 42 | + 4. Devlin Cronin (Google) |
| 43 | + 5. Giorgio Maone (NoScript, Tor) |
| 44 | + 6. Timothy Hatcher (Apple) |
| 45 | + 7. Kiara Rose (Apple) |
| 46 | + 8. Lena Cohen (Privacy Badger, EFF) |
| 47 | + 9. Carlos Jeurissen (Jeurissen Apps) |
| 48 | + 10. Harsh Singh (Google Summer of Code) |
| 49 | + 11. Jordan Spivack (Capital One) |
| 50 | + 12. David Vaisbrud (LayerX) |
| 51 | + 13. Mukul Purohit (Microsoft) |
| 52 | + |
| 53 | + |
| 54 | +## Meeting notes |
| 55 | + |
| 56 | +[Issue 843](https://github.com/w3c/webextensions/issues/843): TPAC registration is open, we have ~12 hours of [meeting time scheduled](https://github.com/w3c/webextensions/issues/843#issuecomment-3140015582) across Monday and Thursday. |
| 57 | + |
| 58 | + * [simeon] TPAC registrations are open. The meeting schedule is also published; we have 12 hours of meeting time split over Monday and Thursday. |
| 59 | + |
| 60 | +[Issue 849](https://github.com/w3c/webextensions/issues/849): Inconsistency: native messaging size limit |
| 61 | + |
| 62 | + * [simeon] Didn't we discuss this last time? |
| 63 | + * [rob] Chrome's perspective was missing; also in the meantime additional discussion happened on the issue. |
| 64 | + * [simeon] The author is asking for browsers to provide chunking so that native messaging limits are not exposed to extensions. |
| 65 | + * [rob] That's an assumption on the implementation, and not necessarily the technical reason. |
| 66 | + * [simeon] They'd like a higher limit. |
| 67 | + * [rob] 1 MB can be higher, but what limit would be good enough? |
| 68 | + * [devlin] Heard of use case like JSON-encoding a video, in which case 64 MB is too small. Realistic use cases also include password stores, which could be large, and 1 MB would be too small. We could bump to 64 MB, and also have other ways to overcome IPC limits. But as the native messaging implementation is not optimal, we're concerned about the impact. And size limitations discourages using native messaging for these data-intensive use cases. Recommend using localhost & web transport mechanisms instead. |
| 69 | + * [rob] Aren't browsers locking down localhost access? |
| 70 | + * [devlin] Arguably, but this is in extensions. On the web the ability to run a native application is a sandbox escape, but it's acceptable in extensions. |
| 71 | + * [rob] Requires a server to be continuously running, a bit different than dropping a file in a location and letting the browser launch it. |
| 72 | + * [devlin] Mostly just trying to say that I'm not convinced increasing the native messaging limit is the right path. |
| 73 | + * [rob] Are we willing to raise the limit from 1 MB (native app-to-browser) and 64 MB (browser-to-native app) or possibly higher?. |
| 74 | + * [devlin] Hesitant to raise beyond 64 MB because copying string buffers larger than that is nontrivial and has performance implications. |
| 75 | + * [rob] 64 MB is a reasonable limit from extensions to native messaging host, but the opposite direction is 1MB. Are we in favor of raising that limit to 64 MB? |
| 76 | + * [devlin] Have to look into why we are at 1 MB, but in principle amendable to raising the limit to 64 MB. |
| 77 | + * [kiara] 64 MB in either direction works for Safari, as long as 80 MB is not exceeded (due to xpc service limits). |
| 78 | + * **Consensus**: alignment on raising limit to 64 MB in either direction. |
| 79 | + * [rob] Do we want to set an environment variable or something to expose limits to native applications? |
| 80 | + * [tomislav] They can always test the limits manually, so there's no reason to hide this variable. |
| 81 | + |
| 82 | +[Issue 855](https://github.com/w3c/webextensions/issues/855): Proposal: Clarify the scale parameter for tabs.captureVisibleTab |
| 83 | + |
| 84 | + * [devlin] We added “rect” for a visible region, and noticed that “scale” does something different. Our implementation right now () uses “scale” to scale from device independent pixels to pixels, opposed to actually upscale the captured region. |
| 85 | + * [rob] Tomislav, I think you touched this last, do you know anything about it? |
| 86 | + * [tomislav] We use it as a scale parameter for dpi calculations. |
| 87 | + * [devlin] If you have device pixels and css pixels 1:1, and pass a scale of 2, what is the captured region in Firefox? |
| 88 | + * [tomislav] Should behave as if you manually changed the scale to 200%. |
| 89 | + * [devlin] In that case, would it change the captured region too? |
| 90 | + * [rob] That's strange. That would also imply reflow and rerender of the content, whereas this API is supposed to just capture what is displayed. |
| 91 | + * Action item: Tomislav to to investigate how the current implementation works and follow up on the bug. |
| 92 | + |
| 93 | +[Issue 856](https://github.com/w3c/webextensions/issues/856): Inconsistency: browser.downloads.download API can ignore file name extension if MIME is known type |
| 94 | + |
| 95 | + * [rob] It seems the request is to be able to set a specific file name. Firefox's file name handling is more permissive than Chrome's. I know Chrome will rename the filename in more cases. |
| 96 | + * [devlin] I'm surprised that we strip the custom file extension. I don't know if there are extensions reliant on this behavior. What if the MIME type and file extension don't match? |
| 97 | + * [rob] I wonder if this could be overridden using the onDeterminingFilename event in Chrome. Firefox doesn't support this, but Chrome does. If you're concerned about existing extensions, we could introduce a parameter to explicitly change behavior. |
| 98 | + * [devlin] Think we should see what we can do to gather more information about all the various scenarios, what all the browsers do, and follow up on a solution that works as broadly as possible. |
| 99 | + * [rob] Could someone from Chrome look into whether the behavior is expected and/or find a crbug? |
| 100 | + |
| 101 | +[Issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains) ([@lenacohen](https://github.com/lenacohen)) |
| 102 | + |
| 103 | + * [lena] Feature request where all browsers are supportive; wondering about the implementation status. We have another use case: PrivacyBadger is trying to add site-specific allow rules. Planning to work around this by handling site-specific rules via tab-scoped rules. Obviously a potential race condition with this approach. Wanted to see if we can address this issue and curious if other blocking extensions have identified other workarounds. |
| 104 | + * [devlin] On Chrome side we're supportive; an external contributor Dave Vandyke started the work and updated the patch set this morning. Might be available after next week's branch. |
| 105 | + * [rob] This was a Google Docs proposal, I don't think that it ever made it into a WECG proposal |
| 106 | + * [simeon] Will it land in Chrome first and then in the other browsers? |
| 107 | + * [devlin] Hoping to land this soon, so I guess that depends on how quickly other browsers get to it ;) |
| 108 | + * [rob] I'll create a Bugzilla issue on Firefox's side. |
| 109 | + * [rob] How about Safari? |
| 110 | + * [kiara] We're supportive of this, but no timeline yet. |
| 111 | + * [lena] Glad to hear all of this. |
| 112 | + |
| 113 | +[PR 817](https://github.com/w3c/webextensions/pull/817): Proposal: Focus management API |
| 114 | + |
| 115 | + * [simeon] I'm overdue on update on sidebar focus proposal; how much time do you have on the Chrome side for GSoC. Wondering if I should prioritize this proposal? |
| 116 | + * [devlin] Harsh is here. On the Chrome side we're making our way through. Not exactly sure on end timeline. |
| 117 | + * [harsh] GSoC ends on August, 25th. |
| 118 | + * [simeon] My interpretation of that is sooner is better than later. Thank you. |
| 119 | + |
| 120 | +Extra time, any topics? |
| 121 | + |
| 122 | + * [lena] PSA: A German appeals court is considering whether to ban adblockers on the grounds that they are creating derivative works of webpages (https://www.golem.de/sonstiges/zustimmung/auswahl.html?from=https%3A%2F%2Fwww.golem.de%2Fnews%2Furheberrecht-von-webseiten-bgh-haelt-unzulaessigkeit-von-adblockern-fuer-moeglich-2507-198676.html ) |
| 123 | + * [devlin] Is this related to the Springer one? |
| 124 | + * [lena] Yes, the one vs Eyeo. |
| 125 | + |
| 126 | +[Issue 616](https://github.com/w3c/webextensions/issues/616): Content script injection inconsistencies in the sidePanel |
| 127 | + |
| 128 | + * [david] Say I have permission to open [example.com](http://example.com/) and this is opened in the sidebar, from what I can tell in Firefox we are able to inject script but in other browser we cannot. Is this the intended behavior? |
| 129 | + * [devlin] I would expect content scripts to run in web frames and iframes within an extension's own context. From the issue it sounds like it was correctly run. |
| 130 | + |
| 131 | +DNR / Content Script compatibility with non-tab contexts (such as sidebars) (Maone) |
| 132 | + |
| 133 | + * [giorgio] DNR processes requests for AI websites in sidebar, where content is blocked, without a way to show UI/UX to allow requests. Maybe treat sidebar as special tabs? E.g. negative tab ID that is not -1. |
| 134 | + * (rob: FYI relevant issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1974303 ) |
| 135 | + * [rob] If we were to offer a way to target sidebars, how would you use it? |
| 136 | + * [giorgio] The UI that I have should not be displayed on all tabs, only in sidebars. |
| 137 | + * [rob] Issue 616 is about content scripts; do we have an issue for DNR in the sidebar? |
| 138 | + * [giorgio] I don't think we have one explicitly for that. |
| 139 | + * [rob] Could you create an issue to cover your use case and the fix you'd like to see? |
| 140 | + * [giorgio] Okay. |
| 141 | + |
| 142 | +[PR 852](https://github.com/w3c/webextensions/pull/852#discussion_r2225631737): WPT update, also quick assertTrue discussion |
| 143 | + |
| 144 | + * [tomislav] Merged the PR yesterday |
| 145 | + * [kiara] Updated the RFC. |
| 146 | + * [tomislav] also responded to jgraham. |
| 147 | + * [kiara] I'll rebase the wpt PR and ping them in the channel. |
| 148 | + * [tomislav] on `test.assertTrue`, I investigated common/popular assertion libraries, none of them have a method with this exact name, and usually the common “truthy” assert is called `ok()` or just `assert()`. |
| 149 | + * [tomislav] There is a discrepancy between Chrome, Firefox and Safari: Chrome has strict === true in assertTrue, Firefox/Safari treat it as truthy. |
| 150 | + * [devlin] I prefer strict equality for true, to prevent unexpected things, so that when assertTrue is used, that it passed when true is passed, and not for 7. |
| 151 | + * [tomislav] assertEq can be used for that. |
| 152 | + * [devlin] But that's weird. |
| 153 | + * [rob] Could introduce something else to address the truthy use case. |
| 154 | + * [tomislav] Could. Would require more work for us to convert to that new value, but not against it. |
| 155 | + * [timothy] I see the appeal of no accidental conversions; I'm fine making it strict for assertTrue and assertFalse. |
| 156 | + * [tomislav] Should we pursue introducing assert.ok for the general case? |
| 157 | + * [timothy] I'd be fine with it if we find it useful. |
| 158 | + * [devlin] `assertTrue(!!` |
| 159 | + |
| 160 | +We did not verbally discuss the following items, but participants added comments during other discussions. |
| 161 | + |
| 162 | +[Issue 116 comment](https://github.com/w3c/webextensions/issues/116#issuecomment-3032442917): Proposal: stop adding `host_permissions` from `content_scripts` |
| 163 | + |
| 164 | + * [carlos] Is there a conceptual difference between content script permissions and host permissions? Relevant to permissions.canAccess(). |
| 165 | + * [tomislav] Either content scripts can run, and access it with a permission, or you don't. |
| 166 | + * _[carlos, async] Question to Devlin: is this expected behaviour in this comment from Fregante? _ |
| 167 | + * [devlin, async] it's unsurprising, though I wouldn't necessarily say desirable. Right now, the permissions API only looks at host_permissions (or, historically, `permissions`), so it didn't take into account the permissions in content_scripts (whereas our permission warnings obviously do). I'd be supportive of changing that, especially with permissions.hasAccess(), if there's a good way to indicate it |
| 168 | + * [carlos, async] thanks for your response! gotcha, so it would make sense to merge these two concepts, there is some “active” discussion on it here: https://github.com/w3c/webextensions/pull/799#discussion_r2080111012 |
| 169 | + |
| 170 | +[Pull 799 comment](https://github.com/w3c/webextensions/pull/799#discussion_r2080111012): Add `browser.permissions.canAccess()` proposal |
| 171 | + |
| 172 | + * _[carlos, async] Do we want to distinguish scriptAccess and hostAccess?_ |
| 173 | + * [simeon, async] That feels like a useful distinction. It's worth noting that we don't currently have this separation of concepts, but maybe we should. |
| 174 | + |
| 175 | +The next meeting will be on [Thursday, August 14th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=689e7880,384). |
0 commit comments