|
| 1 | +# WECG Meetings 2025, Public Notes, Apr 24 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=68097f00,384 |
| 7 | +Call-in details: [WebExtensions CG, 24th April 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250424T080000/) |
| 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 #810](https://github.com/w3c/webextensions/issues/810), [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 | + * [rob] Berlin F2F meeting notes published: https://github.com/w3c/webextensions/pull/814 |
| 19 | + * **Triage** (15 minutes) |
| 20 | + * [Issue 803](https://github.com/w3c/webextensions/issues/803): Proposal: Added Sync management APIs |
| 21 | + * [Issue 811](https://github.com/w3c/webextensions/issues/811): [Feature Request] Add Parameters to The menus.onHidden Listener |
| 22 | + * [Issue 812](https://github.com/w3c/webextensions/issues/812): [Feature Request] Add windows.onBeforeRemoved Event |
| 23 | + * [Issue 815](https://github.com/w3c/webextensions/issues/815): Inconsistency: Retrieving closed shadow roots |
| 24 | + * [Issue 816](https://github.com/w3c/webextensions/issues/816): Proposal: Support for xdg-activation in windows |
| 25 | + * **Timely issues** (10 minutes) |
| 26 | + * [PR 813](https://github.com/w3c/webextensions/pull/813): Use Install/Uninstall action names in WD classic |
| 27 | + * (Draft) [PR 817](https://github.com/w3c/webextensions/pull/817): Proposal: Focus management API |
| 28 | + * **Check-in on existing issues** (20 minutes) |
| 29 | + * [PR 802](https://github.com/w3c/webextensions/issues/802): Add proposal for topFrameMatches and excludeTopFrameMatches (leftover from previous meeting) |
| 30 | + * [Issue 90](https://github.com/w3c/webextensions/issues/90): Proposal: unique frameIds across windows and tabs |
| 31 | + * ([@carlosjeurissen](https://github.com/carlosjeurissen)) Objectives: check current implementation state, check browser support |
| 32 | + * [Issue 92](https://github.com/w3c/webextensions/issues/92): Inconsistency: runtime.onMessage listening for contentScript messages within extension popups |
| 33 | + * ([@carlosjeurissen](https://github.com/carlosjeurissen)) Objective: determine if Safari is willing to follow Chrome and Firefox behaviour |
| 34 | + * [Issue 774](https://github.com/w3c/webextensions/issues/774): Inconsistency: contextMenus/Menus |
| 35 | + * ([@carlosjeurissen](https://github.com/carlosjeurissen)) Objective: determine support for falling back to parent context, determine support on aligning default, if helpful, split issue |
| 36 | + * [PR 798](https://github.com/w3c/webextensions/pull/798): Proposal "Allow to change permissions behavior on extension updates" |
| 37 | + * ([@oleksiilevzhynskyi](https://github.com/oleksiilevzhynskyi)) Objective: technical clarification ([comment](https://github.com/w3c/webextensions/pull/798#issuecomment-2822635045)) |
| 38 | + |
| 39 | + |
| 40 | +## Attendees (sign yourself in) |
| 41 | + |
| 42 | + 1. Rob Wu (Mozilla) |
| 43 | + 2. David Tota (AdGuard) |
| 44 | + 3. Maxim Topciu (AdGuard) |
| 45 | + 4. Oliver Dunk (Google) |
| 46 | + 5. David Johnson (Apple) |
| 47 | + 6. Timothy Hatcher (Apple) |
| 48 | + 7. Kiara Rose (Apple) |
| 49 | + 8. Oleksii Levzhynskyi (Grammarly) |
| 50 | + 9. Carlos Jeurissen (Jeurissen Apps) |
| 51 | + 10. Mukul Purohit (Microsoft) |
| 52 | + 11. Kees Kluskens (Tango) |
| 53 | + 12. Simeon Vincent (Mozilla) |
| 54 | + |
| 55 | + |
| 56 | +## Meeting notes |
| 57 | + |
| 58 | +Berlin F2F meeting notes |
| 59 | + |
| 60 | + * [rob] Berlin F2F meeting notes published: https://github.com/w3c/webextensions/pull/814 |
| 61 | + |
| 62 | +[Issue 803](https://github.com/w3c/webextensions/issues/803): Proposal: Added Sync management APIs |
| 63 | + |
| 64 | + * [rob] I haven't had a chance to look into it yet. |
| 65 | + * [oliver] I took a brief look, but I don't know if I have a grasp of the issue. It seems to relate to making changes on one device and seeing if the onChange event is fired for the same device. |
| 66 | + * [timothy] They want to know if the change was triggered locally vs from the remote end. |
| 67 | + * [rob] Sounds reasonable if we can support it. |
| 68 | + * [oliver] Does anyone know if we fire the onChange event on the same device? |
| 69 | + * [oliver] Well, I guess across contexts it does make sense to do this. |
| 70 | + * [rob] Even without dedicated API support extensions can already broadcast a message before making changes. |
| 71 | + * [timothy] Safari does currently not support sync storage. I'll defer to other browsers that implement sync storage. |
| 72 | + * [rob] We (Oliver and I) will have to look at this further and revisit later. |
| 73 | + |
| 74 | +[Issue 811](https://github.com/w3c/webextensions/issues/811): [Feature Request] Add Parameters to The menus.onHidden Listener |
| 75 | + |
| 76 | + * [rob] Firefox-only event. This event fires when the menu is shown and hidden. Only fires for top-level menu and not submenus. |
| 77 | + * [rob] Does Safari have the menus API? |
| 78 | + * [timothy] We support menus API, but not onHidden. |
| 79 | + * [rob] I'll respond to this issue and then close it out. No cross-browser discussion to be had. |
| 80 | + |
| 81 | +[Issue 812](https://github.com/w3c/webextensions/issues/812): [Feature Request] Add windows.onBeforeRemoved Event |
| 82 | + |
| 83 | + * [rob] I don't think that we can support this. |
| 84 | + * [carlos] You can already do this with content scripts so it doesn't make sense to implement. |
| 85 | + * [rob] There are already cases where onbeforeunload is ignored. It seems complicated to add. |
| 86 | + * [timothy] I agree that this would be complicated. Don't think we would be supportive. |
| 87 | + * [oliver] +1 to what you said. |
| 88 | + |
| 89 | +[Issue 815](https://github.com/w3c/webextensions/issues/815): Inconsistency: Retrieving closed shadow roots |
| 90 | + |
| 91 | + * [rob] This is about open and closed shadow roots. Isn't there another issue for this? |
| 92 | + * [rob] Firefox is not opposed to implementing this on the dom namespace with a method. |
| 93 | + * [timothy] We are open to exposing this. We would only expose it to the content script world. |
| 94 | + * [rob] On the dom namespace, or the element? |
| 95 | + * [timothy] Leaning towards Firefox's approach (`element.openOrClosedShadowRoot`). Reluctant to introducing dom namespace where we can have it on element. |
| 96 | + * [oliver] dom namespace in general or this method specifically? |
| 97 | + * [timothy] What else is on the dom namespace? |
| 98 | + * [oliver] Currently nothing, but there are proposals to add more. |
| 99 | + * [timothy] Less opposed if there are more, would be more concerned if it is just one method. |
| 100 | + * [oliver] Since we are going to add more to dom, happy to continue with dom. If Firefox and Safari prefer adding it to Element, we can consider the same. |
| 101 | + * [oliver] Should we mention on the issue using the dom namespace and add supportive labels? |
| 102 | + * [rob] If that is the direction we want to go in. We are also discussing moving towards web-like APIs. |
| 103 | + |
| 104 | +[Issue 816](https://github.com/w3c/webextensions/issues/816): Proposal: Support for xdg-activation in windows |
| 105 | + |
| 106 | + * [rob] Does anyone have context here? |
| 107 | + * [timothy] I don't have context here, and this is Linux-specific and therefore not affecting Safari, so I'll mark us as neutral. |
| 108 | + * [rob] Triage this issue async and move on. |
| 109 | + |
| 110 | +[PR 813](https://github.com/w3c/webextensions/pull/813): Use Install/Uninstall action names in WD classic |
| 111 | + |
| 112 | + * [kiara] Request was to rename load/unload to install/uninstall to better match the name from the WebDriver-bidi spec, so we made the changes. |
| 113 | + * [oliver] We are not going to implement WD classic, but the intent was always to align with bidi as close as possible, so looks good to me. |
| 114 | + * [timothy] Looks good to me. |
| 115 | + * [rob] Since Tomislav opened it, I suppose that we are also good with this from the Firefox side. |
| 116 | + |
| 117 | +(Draft) [PR 817](https://github.com/w3c/webextensions/pull/817): Proposal: Focus management API |
| 118 | + |
| 119 | + * [rob] Seems Simeon is not here to speak to this one. Does anyone have anything to discuss? |
| 120 | + * [carlos] sidepanel does not get focus when opened, which does not align with extension popup. |
| 121 | + * [rob] action popup draws attention and reasonably receives focus. Sidepanel may appear passively without requiring immediate attention. |
| 122 | + * [oleksii] This is about switching focus from the side panel to the page. It would be useful to be able to do the reverse as well, since the side panel will be used as an assistant that the user will jump back and forth between. |
| 123 | + * [oliver] Open question on the Chrome team - are there restrictions on the web on moving focus between frames / cross-origin iframes? If there are, this may be relevant here. |
| 124 | + * [timothy] Recall focus() not being callable on frames in some cases. There is also autofocus attribute that can take focus from location field on page load. |
| 125 | + * [oleksii] same-origin may be fine, cross-origin may be trickier. |
| 126 | + * [oliver] We can potentially say that extensions have a higher level of trust. |
| 127 | + * [oleksii] Maybe in this case it should possibly not be unexpectedly, but require a user gesture. |
| 128 | + * [timothy] Extensions can already open tabs and steal focus, I don't know if abuse surface is increased by this. |
| 129 | + * [rob] Since this is a draft and Simeon is not here, we can revisit this later. |
| 130 | + * |
| 131 | + * [simeon] (joined later) Draft is in a good state and ready for review. Idea here is to control focus in current application, more generic than switching between sidepanel and tab's main content. Forward-compatible with other surfaces that may be focusable in the future. E.g. address bar focus. Or split tab views (in some other browsers). In short, I did not want to be too prescriptive in the surfaces and. |
| 132 | + * [rob] I don't think that we'd ever allow extensions to focus the address bar because of abuse, but other than that it sounds like it makes sense. |
| 133 | + * [timothy] When we discussed before, we were wondering about including frameId, maybe documentId in the API. |
| 134 | + * [simeon] I included that in the “future”, reason for excluding it from the draft is that it is unclear if a specified subframe would change the focus in the document, and what the semantics are. |
| 135 | + * [timothy] May help if the proposal is rephrased in terms of views and not in terms of frames. Previously focused frame is still focused when the view (e.g. webview) is focused. |
| 136 | + * [rob] This was my understanding of when the feature request was raised. |
| 137 | + * [simeon] Makes sense. |
| 138 | + |
| 139 | +[PR 802](https://github.com/w3c/webextensions/issues/802): Add proposal for topFrameMatches and excludeTopFrameMatches |
| 140 | + |
| 141 | + * [carlos] Discussed many times, this PR formalizing what we agreed upon. |
| 142 | + * [rob] Last status, from the Berlin F2F: Firefox/Safari willing to mentor external contributions and be the sponsoring browser in that case. |
| 143 | + * [oleksii] So next step is a proposal? |
| 144 | + * [rob] This is already the proposal. Next step is for an external contributor to express interest in submitting a patch to one of the browsers. |
| 145 | + |
| 146 | +[Issue 90](https://github.com/w3c/webextensions/issues/90): Proposal: unique frameIds across windows and tabs |
| 147 | + |
| 148 | + * [carlos] Objectives: check current implementation state, check browser support |
| 149 | + * [carlos] Is this already there in browsers? Confirm? |
| 150 | + * [timothy] Main issue with frameId in multi-process is that IDs are not unique and may overlap with other processes. There are mitigations, but right now they are not guaranteed to be unique in Safari. |
| 151 | + * [rob] In Firefox and Chrome they are allocated such that they are unique, issue is main_frame frameId 0. |
| 152 | + * [timothy] Possibly superseded by documentId, which is a UUID and globally unique in Safari. |
| 153 | + * [carlos] So opposed in Safari and implemented in Chrome and Firefox? |
| 154 | + * [timothy] Not opposed, but neutral. documentId is future for true uniqueness. |
| 155 | + * [rob] I recall similar discussion before, at [issue 91](https://github.com/w3c/webextensions/issues/91): scripting.executeScript without specifying tabId. |
| 156 | + * [carlos] There are cases in which extensions want to send messages to subFrames in which documentId might not be reliable as navigation might have been changed. Currently to get the documentId you would need to send a message to the background page. Which is not possible in Safari due to issue 92. |
| 157 | + * [rob] Implementation limitation in Safari can be overcome. E.g. allocate a process-specific unique prefix in the parent process and have a process-specific counter. |
| 158 | + * [timothy] We currently do something like that already, but the data types may not fit in a number. |
| 159 | + * [rob] In practice it is extremely unlikely for the number to exceed the limits. |
| 160 | + |
| 161 | +[Issue 92](https://github.com/w3c/webextensions/issues/92): Inconsistency: runtime.onMessage listening for contentScript messages within extension popups |
| 162 | + |
| 163 | + * [carlos] Objective: determine if Safari is willing to follow Chrome and Firefox behaviour |
| 164 | + * [timothy] Definitely an implementation bug in Safari. We prevent sending messages to the same page, but should limit sending to same frame. |
| 165 | + * [rob] Next steps here? Link to Safari issue and once fixed label the issue as supported + close? |
| 166 | + * [timothy] Already linked. |
| 167 | + |
| 168 | +[Issue 774](https://github.com/w3c/webextensions/issues/774): Inconsistency: contextMenus/Menus |
| 169 | + |
| 170 | + * [carlos] Objective: determine support for falling back to parent context, determine support on aligning default, if helpful, split issue |
| 171 | + * [rob] Context menu has many fields, what makes the context so special that it has to be inherited (and not the other fields)? |
| 172 | + * [carlos] The intention for submenus without a context is to be part of the parent. Having it not inherit the top menu, is counter-intuitive. |
| 173 | + * [timothy] Almost like we want menu items to inherit the context of the submenus. |
| 174 | + * [rob] Restrictions from the parent are already applied, a submenu is not visible when the parent is hidden. What you're effectively asking for is to default to “all” when contexts is not explicitly specified. |
| 175 | + * [carlos] (...) can move on. |
| 176 | + |
| 177 | +[PR 798](https://github.com/w3c/webextensions/pull/798): Proposal "Allow to change permissions behavior on extension updates" |
| 178 | + |
| 179 | + * [oleksii] Objective: technical clarification ([comment](https://github.com/w3c/webextensions/pull/798#issuecomment-2822635045)) |
| 180 | + * [oleksii] If key is set to defer, the permissions won't be changed, but extensions will have to request permissions. In theory it would be great if there is a way for extensions to restore broken extensions. What if someone accidentally releases a new permission with a warning that disables the update, and then publishes an update with property set to defer. |
| 181 | + * [carlos] Reminds me of MV2/MV3; MV2 was disabled in Chrome, when MV3 is published, it is re-enabled. Not sure if it applies to permissions as well. |
| 182 | + * [oliver] Sounds reasonable. |
| 183 | + * [oleksii] Is it technically feasible from the browser perspective? |
| 184 | + * [oliver] Makes sense to me. I'd add it. |
| 185 | + * [rob] This could work in Firefox. Although we don't disable the extension, we do check permission changes from update responses, and postpone updates if the user did not consent. We can account for a new flag. |
| 186 | + * [timothy] Should be feasible for us too, even in Safari. |
| 187 | + * [oleksii] I will update the proposal. What are next steps? |
| 188 | + * [timothy] Don't recall exactly, but I believe at least two reviewers need to approve? |
| 189 | + * [rob] This issue is most prominently experienced in Chrome, so at minimum I'd tag Oliver as reviewer. The PR currently has reviews assigned to Chrome, Firefox, Safari. |
| 190 | + |
| 191 | +The next meeting will be on [Thursday, May 8th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=681bf400,384). |
0 commit comments