|
| 1 | +# WECG Meetings 2025, Public Notes, Mar 13 |
| 2 | + |
| 3 | + * Chair: Kiara Rose |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=67d22000,384 |
| 7 | +Call-in details: [WebExtensions CG, 13th March 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250313T080000/) |
| 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 #772](https://github.com/w3c/webextensions/issues/772), [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 773](https://github.com/w3c/webextensions/issues/773): Disable external communication possibilities with externally_connectable |
| 20 | + * [Issue 774](https://github.com/w3c/webextensions/issues/774): Inconsistency: contextMenus/Menus |
| 21 | + * [Issue 776](https://github.com/w3c/webextensions/issues/776): Proposal: Unpacked \_locales |
| 22 | + * **Timely issues** (10 minutes) |
| 23 | + * [Issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains) ([@oliverdunk](https://github.com/oliverdunk)) |
| 24 | + * [Issue 763](https://github.com/w3c/webextensions/issues/763): Proposal: Add `mainFrameMatches` / `excludeMainFrameMatches` ([@carlosjeurissen](https://github.com/carlosjeurissen)) |
| 25 | + * **Check-in on existing issues** (20 minutes) |
| 26 | + * [Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API ([@oliverdunk](https://github.com/oliverdunk)) |
| 27 | + * [PR 779](https://github.com/w3c/webextensions/pull/779/files): Proposal for sidePanel lifecycle events. ([@rishikramena-ms](https://github.com/rishikramena-ms)) |
| 28 | + * [PR 690](https://github.com/w3c/webextensions/pull/690): Proposal for cookies.removeAll API ([@aselya](https://github.com/aselya)) |
| 29 | + |
| 30 | + |
| 31 | +## Attendees (sign yourself in) |
| 32 | + |
| 33 | + 1. Oliver Dunk (Google)[ |
| 34 | + 2. Rob Wu (Mozilla) |
| 35 | + 3. Simeon Vincent (Mozilla) |
| 36 | + 4. Solomon Kinard |
| 37 | + 5. Sohail Rajdev (Microsoft) |
| 38 | + 6. Kiara Rose (Apple) |
| 39 | + 7. Martin Verde (Google) |
| 40 | + 8. Timothy Hatcher (Apple) |
| 41 | + 9. Maxim Topciu (AdGuard) |
| 42 | + 10. David Tota (AdGuard) |
| 43 | + 11. Tim Pillard (Dashlane) |
| 44 | + 12. Timothy Hatcher (Apple) |
| 45 | + 13. Tomislav Jovanovic (Mozilla) |
| 46 | + 14. Cameron Eckelberry (Malwarebytes) |
| 47 | + 15. Rishik Ramena (Microsoft) |
| 48 | + 16. Todd Schiller (PixieBrix) |
| 49 | + 17. Jordan Spivack (Capital One) |
| 50 | + 18. David Johnson (Apple) |
| 51 | + 19. Giorgio Maone (Tor, NoScript) |
| 52 | + 20. Mostafa Aboalkasim (Individual) |
| 53 | + 21. Mukul Purohit (Microsoft) |
| 54 | + 22. Aaron Selya (Google) |
| 55 | + |
| 56 | + |
| 57 | +## Meeting notes |
| 58 | + |
| 59 | +Berlin F2F Reminder |
| 60 | + |
| 61 | + * [kiara] Developers can sign up for the State of the Extensions |
| 62 | + * [simeon] Agenda is work in progress; |
| 63 | + * [timothy] Thursday and Friday are still sparse, with some room for small topics on Tuesday. |
| 64 | + * [oliver] Agenda: https://github.com/w3c/webextensions/issues/778 |
| 65 | + * [lena] Have details about virtual attendance been shared? |
| 66 | + * [simeon] Short answer, we plan to stream the content on Zoom. We have existing items on the WECG calendar that our members can see. I'll add a link to each of the individual events in the schedule on the wiki. |
| 67 | + * [rob] If you have difficulty joining the meeting, join the chat on matrix and ping us. |
| 68 | + |
| 69 | +[Issue 773](https://github.com/w3c/webextensions/issues/773): Disable external communication possibilities with externally_connectable |
| 70 | + |
| 71 | + * [kiara] Agree with the ask - to disallow other extensions to connect. |
| 72 | + * [timothy] Surprise that any extension can connect. |
| 73 | + * [oliver] These are soft warnings. |
| 74 | + * [timothy] Any idea how many extensions use this? |
| 75 | + * [rob] Some on Firefox. Tree Style Tabs allows other extensions to extend it. |
| 76 | + * [rob] Firefox does not support externally_connectable (=allow web page to notify extension), but does allow cross-extension communication. Instead of onMessage/onConnect, onMessageExternal/onConnectExternal is triggered, and extensions SHOULD validate the source of the message. |
| 77 | + * [simeon] I think the intent was that you have a separate event listener for external messages, so a developer would have to intentionally opt into receiving and responding to messages. |
| 78 | + * [timothy] Since it comes through a dedicated event, it's not a foot gun. |
| 79 | + |
| 80 | +[Issue 774](https://github.com/w3c/webextensions/issues/774): Inconsistency: contextMenus/Menus |
| 81 | + |
| 82 | + * [kiara] I tested in Safari, and the emojis show up as expected. |
| 83 | + * [timothy] Looks more like an implementation issue in Chrome. |
| 84 | + * [simeon] Rob, context on why Firefox defaults to ‘all'? |
| 85 | + * [rob] Firefox does default to “page” when there is no more specific context (e.g. image, input). When you create a context menu through the API but don't provide a context, defaults to “all”', which is essentially page + other contexts that aren't page-related (bookmarks, tools_menu, tab - not implemented by Chrome). |
| 86 | + * [timothy] We support tab like Firefox; we default to “page” if not explicitly specified. |
| 87 | + * [rob] Reasoning for this default in Safari? |
| 88 | + * [timothy] First matched Chrome's behavior, and then added “tab” later. |
| 89 | + * [rob] Is there a desire to change the default? |
| 90 | + * [timothy] Likely wouldn't affect too much if we changed the default. I can look into that. |
| 91 | + * [rob] Backcompat issue if we were to change the default from all to page in Firefox. |
| 92 | + * [simeon] Flagged this issue as “next manifest version”. |
| 93 | + |
| 94 | +[Issue 776](https://github.com/w3c/webextensions/issues/776): Proposal: Unpacked \_locales |
| 95 | + |
| 96 | + * [kiara] Request to allow users to customize translations. |
| 97 | + * [oliver] UI proposal to modify the translations is out of scope; 2nd part of proposal is to add a directory to allow users to translate. |
| 98 | + * [rob] Not much appetite for this on our side. Adds complexity. Hardcoded strings cannot be modified, only if extensions use the i18n API. |
| 99 | + * [rob] Opposed from Firefox's side. |
| 100 | + * [oliver] Opposed from Chrome's side too. |
| 101 | + * [timothy] Opposed from Safari's side (instead of neutral), to align. |
| 102 | + * [simeon] This is something that an extension could do on its own if it wanted to. In general I'd love to see more libraries exploring solutions for these kinds of issues. |
| 103 | + |
| 104 | +[Issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains) |
| 105 | + |
| 106 | + * [oliver] Additional comments on the issue, please take a look. |
| 107 | + * [oliver] Interesting edge case from Alexei, how mailto link should be handled. E.g. mailto link blocked on initiator, is that initiated by the content or a new tab? In Chrome it would be the page you click the link. |
| 108 | + * [rob] In Firefox it would also be the initiator. In our impl DNR wouldn't block this case, since we only process http and https requests. |
| 109 | + * [alexei] I only looked at the Gmail in Chrome case. If you set up Chrome to have Gmail handle mailto links, then xmlhttprequest type requests to mail.google.com are blocked on a new mail.google.com tab that gets opened in response to clicking the mailto link, despite the DNR rule specifying “domainType” as thirdParty. So is this a domainType bug? |
| 110 | + * [rob] Please share the STR and issue somewhere. |
| 111 | + * [alexei] Documented here: https://github.com/EFForg/privacybadger/issues/3066 |
| 112 | + * [oliver] Would be interesting to know more about how these cases are handled. |
| 113 | + * [rob] Browser passes the different protocol to the OS and it routes the request to the registered protocol handler. I imagine that if the external protocol handler then opens it in the browser again, that the initiator is lost. |
| 114 | + * [oliver] Do all cases get routed through the OS? |
| 115 | + * [rob] In Firefox we query the OS and prompt the user before launching the protocol handler. |
| 116 | + * [timothy] Safari does similarly, can also turn it into a web page request; don't know if we would maintain initiator relationship. |
| 117 | + * [oliver] Sounds like it may be out of scope as it's implementation specific. |
| 118 | + * [timothy] Mailto might be a special case for Chrome due to Gmail. Don't know if any other browser has similar redirection cases. |
| 119 | + * [rob] Was there anything else to discuss here, or was it just to draw attention to the mailto case? |
| 120 | + * [oliver] There's [a Chrome proposal](https://docs.google.com/document/d/1EXTQM_jK5gGu7jj3lMSLSUcucjbTMxyhC3M99HQa9kQ/edit?tab=t.0#heading=h.x9snb54sjlu9) from a contributor that could use a look. We should prepare a WECG PR as well. |
| 121 | + |
| 122 | +[Issue 763](https://github.com/w3c/webextensions/issues/763): Proposal: Add `mainFrameMatches` / `excludeMainFrameMatches` |
| 123 | + |
| 124 | + * [timothy] Similar to the previous issue, but for Content Scripts. My main concern here is naming consistency. We should use the same terminology in both places. |
| 125 | + * [oliver] I see discussion on aligning with other extension APIs. |
| 126 | + * rob] Main frame is currently only used by DNR/webRequest.ResourceType. “top” as a concept may be more familiar to those familiar with the web platform. |
| 127 | + * [oliver] Last time I mentioned not matching by path. Is that reflected in the issue? |
| 128 | + * [timothy] Why is that a requirement? |
| 129 | + * [oliver] For cross-process iframes, we don't have the full URL of the top frame. |
| 130 | + * [timothy] Webkit doesn't have that concept. If other browsers need that restriction that's fine. |
| 131 | + * [rob] Firefox also doesn't have the full URL for cross-origin browsing contexts. Matching would be more complicated if we had to account for path changes from ancestors, e.g. when history.pushState/replaceState is used to change the path. |
| 132 | + |
| 133 | +[Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API |
| 134 | + |
| 135 | + * [oliver] Martin is in the call. |
| 136 | + * [martin] Proposal is for input URLs to be matched against trimmed dots and normalized characters; Rob asked for a specification of behavior, which I put in the issue at https://github.com/w3c/webextensions/issues/770#issuecomment-2695064750. |
| 137 | + * [rob] Wondering if this could have any visible behavior changes. Could Chrome analyze the change against existing extensions? |
| 138 | + * [oliver] For FQDN I imagine that there are barely any. |
| 139 | + * [rob] Not looking to collect new data. You already have published extensions. You could check if the existing URL filter rules contain any characters you're looking to normalize. |
| 140 | + * [oliver] I thought that we only normalize input URLs? |
| 141 | + * [martin] In order to write rules that fit in this format, I expect that developers \*could\* need to rewrite their rules. |
| 142 | + * [oliver] That case might be worth looking at, then. |
| 143 | + * [tomislav] Like Rob, curious if you have data about existing use of fully qualified domain names. Wondering if there are cases that apply different rules targeting domains with and without the final dot. |
| 144 | + * [rob] Last time we discussed this we identified that web servers could respond differently. Martin mentioned the possibility of implementing this behind a flag to enable toggling this behavior. One existing case where we do normalization: FQDN followed by a query parameter. That may make it unusable for certain classes of extensions. |
| 145 | + * [oliver] If we had data showing there weren't any concerns with this change, would other browsers be interested? |
| 146 | + * [rob] Suspect we could align. |
| 147 | + * [martin] Also curious to hear from other browsers if they do something drastically different. |
| 148 | + * [timothy] The normalization you've mentioned seems typical. Curious whether we be trying to do something similar for match patterns. |
| 149 | + * [rob] That would be scope creep, I think. For content scripts we work against the canonical URL. |
| 150 | + * [oliver] Asked my last question to see if it was worth implementing behind a flag. Sounds like there's a desire to do it without a flag, though. |
| 151 | + * [rob] Would be good to hear directly from developers. |
| 152 | + * [martin] Haven't done large scale outreach on this. Might be a good action item. |
| 153 | + |
| 154 | +[PR 779](https://github.com/w3c/webextensions/pull/779/files): Proposal for sidePanel lifecycle events. ([@rishikramena-ms](https://github.com/rishikramena-ms)) |
| 155 | + |
| 156 | + * [rishik] We can review async, but there were a couple decision points worth highlight. Should there be a reason associated with the onOpen and onClosed events? Would adding onHidden, onShown or onVisibilityChanged events for side panel extensions make sense too? onClosed and onOpened events will be fired for any path in the extension. Should we also consider having path-specific events and more granular controls for such cases? |
| 157 | + * [rob] Questions are posed in the “Open for discussions” section at the end of the PR: https://github.com/w3c/webextensions/blob/7e89fbce783f74e247f4ee99786de9801f75a4dc/proposals/sidepanel_events.md?plain=1#L143 |
| 158 | + * [todd] Current challenge: What if a different extension opens a sidepanel, or the browser opens a native sidepanel. |
| 159 | + * … |
| 160 | + * [todd] page visibility API could possibly be used already. |
| 161 | + * [oliver] I think that does work. That only works in the sidepanel, not in the background (work-around are available though). |
| 162 | + * … |
| 163 | + * [rob] In the current proposal there are only USER_ACTION and PROGRAMMATIC reasons for opening the sidebar. What about cases where a panel is open, a new window is created and the existence of the open panel is carried over? |
| 164 | + * [oliver] Doesn't behave that way in Chrome, but could see other browsers doing that. |
| 165 | + |
| 166 | +[PR 690](https://github.com/w3c/webextensions/pull/690): Proposal for cookies.removeAll API ([@aselya](https://github.com/aselya)) |
| 167 | + |
| 168 | + * [aaron] Think I've resolved the outstanding issues, wanted to solicit feedback on the recent changes. Been a while since we last talked about this. |
| 169 | + * [rob] To whom? |
| 170 | + * [aaron] Rob and Timothy. |
| 171 | + * [rob] I'll take a look |
| 172 | + * [timothy] I'll take another look today. |
| 173 | + |
| 174 | +The next meeting will be on [Thursday, March 27th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=67e49500,384). This is in the week of the Face to Face meeting in Berlin, March 25 - 28 ([issue 759](https://github.com/w3c/webextensions/issues/759)). The local time in Europe for this meeting is 4-5 PM instead of the usual time (5-6 PM) due to the difference in Daylight saving time in the USA and Europe. |
0 commit comments