diff --git a/_minutes/2026-02-12-wecg.md b/_minutes/2026-02-12-wecg.md new file mode 100644 index 000000000..23e240a67 --- /dev/null +++ b/_minutes/2026-02-12-wecg.md @@ -0,0 +1,160 @@ +# WECG Meetings 2026, Public Notes, Feb 12 + + * Chair: Kiara Rose + * Scribes: Rob Wu + +Time: 8 AM PST = https://everytimezone.com/?t=698e6980,3c0 +Call-in details: [WebExtensions CG, 12th February 2026](https://www.w3.org/events/meetings/6a0eda89-558c-408d-b83d-5f03b8853c30/20260212T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #946](https://github.com/w3c/webextensions/issues/946), [github issues](https://github.com/w3c/webextensions/issues) + +The meeting will start at 3 minutes after the hour. + +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. + + * **Announcements** (2 minutes) + * [Issue 951](https://github.com/w3c/webextensions/issues/951): 2026 WECG Face to Face (London) + * **Triage** (15 minutes) + * [Issue 948](https://github.com/w3c/webextensions/issues/948): Handling sidebar layout changes + * [Issue 949](https://github.com/w3c/webextensions/issues/949): Specify how icons are chosen given an ideal size - is 'any' preferred or a fallback? + * **Timely issues** (10 minutes) + * **Check-in on existing issues** (20 minutes) + * [Issue 338](https://github.com/w3c/webextensions/issues/338): Inconsistency: runtime.onMessage Promise return + * [PR 932](https://github.com/w3c/webextensions/pull/932): Update runtime.onLoadedReason to match runtime.OnInstalledReason + * [PR 942](https://github.com/w3c/webextensions/pull/942): Proposal: `i18n.getAvailableLanguages()` + * [PR 934](https://github.com/w3c/webextensions/pull/934): Add `runtime.getDocumentId(`) proposal + + +## Attendees (sign yourself in) + + 1. Rob Wu (Mozilla) + 2. Brandon Lucier (1Password) + 3. Kiara Rose (Apple) + 4. Simeon Vincent (unaffiliated) + 5. Dave Vandyke (DuckDuckGo) + 6. Benjamin Bruneau (1Password) + 7. Timothy Hatcher (Apple) + 8. Oliver Dunk (Google) + 9. Carlos Jeurissen (Jeurissen Apps) + 10. Tomislav Jovanovic (Mozilla) + 11. Giorgio Maone (NoScript, Tor) + 12. Jordan Spivack (Capital One) + 13. Casey Garland (Capital One) + 14. Maxim Topciu (AdGuard) + 15. David Johnson (Apple) + 16. Hilary Hacksel (1Password) + + +## Meeting notes + +[Issue 951](https://github.com/w3c/webextensions/issues/951): 2026 WECG Face to Face (London) + + * [kiara] Official issue for our face-to-face meeting in London, including wiki at https://github.com/w3c/webextensions/wiki/2026-London-F2F-Coordination + * [dave] Any deadline on submissions? + * [oliver] Within the next couple of weeks is fine. + +[Issue 948](https://github.com/w3c/webextensions/issues/948): Handling sidebar layout changes + + * [carlos] sidePanel API issue, currently only implemented in Chrome. No way to detect sidepanel layout changes. + * [oliver] I will bring this to the team. Sounds reasonable to have an event to detect layout changes. + * [kiara] We have not implemented sidePanel, but this sounds reasonable. + * [rob] What is the use case? Detecting sidepanel specifically or content sizing? + * [carlos] Content can already be detected in other ways, this is about adjusting the sidepanel's content in response of side changes. + * [rob] I am asking because there are multiple features that can affect the size of what the user sees, e.g. sidepanel and split views. + * [carlos] This is just about detecting changes to the side the sidebar is docked to. For size changes, open web APIs already exist. + * [carlos] Just an additional note on this. Now we talk about this. The behaviour with sidebar and split tab is interesting. Currently Chrome displays the sidebar connected to the current focussed tab. + * [simeon] Do standard web platform events to detect content sizing not work for the use case? + * [carlos] They cannot be used to detect the side of the sidepanel. + * [simeon] So the main use case is detecting which side the sidebar is on when it changes? + * [carlos] Yes. + * [oliver] Chrome introduced getLayout(), but you currently have to poll to detect a change. This would just be an event for data that's already being exposed. + * [] Does Firefox also support sidebars at the right? + * [rob] Yes, in Firefox users can put sidebars at the right. It is not in the sidebarAction API though. + * [carlos] Just to clarify. Firefox does not currently have an API to detect which side this is on. + * [carlos] Since there's no unified sidebar API, how do we want to approach this proposal? + * [oliver] Creating a proposal still makes sense. Not sure who the sponsoring browser would/should be. + * [simeon] Suggest that we approach proposals like this as additions to both sidebarAction and sidePanel, with the intent being that we can directly port the method to a new unified namespace. + * [carlos] Makes sense. + * [rob] Yes, we can then reference existing works in future follow-up proposals. + +[Issue 949](https://github.com/w3c/webextensions/issues/949): Specify how icons are chosen given an ideal size - is 'any' preferred or a fallback? + + * [carlos] Currently icon groups with unknown properties in Webkit are not being skipped. This is in contrast to the icon_variants proposal. + * [timothy] Part where unknown properties are skipped was a bug in the initial implementation. While we don't currently support icon_variants, we don't see a huge issue in adding support. Should definitely fix sooner than later. + * [carlos] Oliver, do you know what behavior Solomon is implementing? + * [oliver] We're open to change. Currently behind a flag. + * [carlos] When you have an icon group, the question is which one gets priority. Is it a specific fixed size, “any”? Want to have clear, deterministic behavior for what takes priority. Currently in WebKit “any” takes priority. Assume that is because they have SVG support and this value would preferably be SVG for resolution independence. + * [timothy] We prefer vector formats over PNG. Not sure if it needs to be specified or be left to browser preference. + * [rob] If someone specifies any with a PNG, you wouldn't want to use that if more specific values are available, would you? + * [timothy] Right now we prefer any regardless of format. In theory you could put a very large PNG that you know resizes well. We could go through and prefer individual sizes, but I suspect we will continue to prefer “any” with a vector. + * [rob] I think it makes sense to respect the extension developer's preference. Presumably if they have a specific size, they have tailored that asset for that size. + * [timothy] The tricky thing for us is that our preferred size is 19 points, not 16. There are devs that tailor assets for every size in every browser, but that's not the typical + * [simeon] Didn't realize 19 was Apple's standard. We should make sure that is reflected in relevant MDN articles. + * [timothy] Changed a few years back. + * [carlos] Chrome used to be 19 in the past. + * [rob] In the icon_variants proposal text, the order of the items is documented as significant, the first matching item is supposed to be matched. + * https://github.com/w3c/webextensions/blob/main/proposals/dark_mode_extension_icons.md + * Permalink: https://github.com/w3c/webextensions/blob/a1cc0afa635e3fe22adddf55c2fb2539f8590cf7/proposals/dark_mode_extension_icons.md#L199-L201 + * [timothy] Since it's an array, it makes sense to follow that as a signal of developer preference. + * [simeon] Concern is approximation of size fallback may not make sense between similar values. For example, 16 converted to 19 or vice versa may not render well. + * [carlos] The proposal clearly specifies how browsers should pick sizes. However what isn't clearly specified is the priority of “any” over sizes. + * [timothy] Open to making changes + * [oliver] New behavior should be documented before any implementation changes. + +[Issue 338](https://github.com/w3c/webextensions/issues/338): Inconsistency: runtime.onMessage Promise return + + * [kiara] Chrome's the last to ship, timeline? + * [oliver] Possibly Chrome 146 or 147. We temporarily shipped earlier on stable but reverted due to compatibility issues. We could keep the issue open until the change is available in Chrome. + * [kiara] Any updates on adding support for WPT testing in Chrome? + * [oliver] No news. + * [dave] In 145 the browser namespace is available. Recently worked on an issue where this affected an extension that stopped using the polyfill. Should you reconsider adding the browser global until this is sorted out? + * [oliver] We are shipping the browser namespace together with the runtime.onMessage Promise return; they are not shipped separately. + * [dave] Sounds good. So not shipping in 145? + * [oliver] Correct. We disabled this via a feature flag in 145. We are now considering a staged rollout for this feature. + * [dave] Would love to know how to test this locally. + * [rob] You can set a CLI flag to manually control the feature flag. + * [oliver] Once the functionality has been stabilized, I will share an update with the version and latest flags. + * [rob] Quick note about status of an issue. So far, what I do is set the `implemented: firefox` label on an issue. Are you doing the same? + * [oliver] I'm open to flipping it to “implemented”. Generally, we use implemented for when it's available in stable. + * [kiara] I'd personally find that confusing. + * [rob] I will adopt that practice from now on. + * [simeon] I see a difference between support signals on MDN vs this group. We are collaborating among people working on the bleeding edge. This is a signal for us, not for the general developer audience. + * [oliver] Does it make sense to use “implemented” if a feature is behind a flag and it is unclear when that flag will be removed? + * [oliver] What about when a feature is landed across 2 CLs. Do we do it on the first or the second? + * [timothy] I think it makes sense to do it on the second, when the feature could be shipped. + * [oliver] Would be helpful to have a clear definition of what we mean by implemented. + * [rob] Shipped might be better tracked in MDN BCD data. In the WECG adding “shipped” would also mean that there is more bookkeeping efforts in managing issue labels. + * [simeon] I can take a shot at writing up some words to describe the different stages for consideration in the next meeting. + * [kiara] Should the label on this be implemented? + * [simeon] I think so. + * [kiara] I've updated the label. + +[PR 932](https://github.com/w3c/webextensions/pull/932): Update runtime.onLoadedReason to match runtime.OnInstalledReason + + * [rob] Already approved by everyone; merged. + +[PR 942](https://github.com/w3c/webextensions/pull/942): Proposal: `i18n.getAvailableLanguages()` + + * [rob] Proposal doesn't currently have a sponsor. + * [timothy] We can do that. + * [carlos] Oliver, you had some concerns? + * [oliver] Yes, not sure it makes sense to have this without a way to switch languages. + * [carlos] First of all. Not all stores allow all locale tags. The build scripts which remove the set of languages from the binary may not be the same build scripts which add the set of supported languages. As for setLanguage and withLanguage, as you mention these are still in proposal phase and not implemented. However I think getAvailableLanguages is a prerequisite for having a polyfill for these APIs. To polyfill setLanguage, you need to know what resource files are in the extension. A library would have to guess and fetch files to determine what resource files are available. + * [oliver] Could be accomplished in a build step. Relatively trivial to generate a static JSON file that lists all available languages. + * [carlos] Can't be accomplished in a runtime library. + * [simeon] Could optimize the lookup operation to take place only in an onInstalled event and cache the results in storage. Not ideal, but a bit better. + * [timothy] Definitely a lot of disk access we wouldn't want extensions to be doing willy-nilly. + +[PR 934](https://github.com/w3c/webextensions/pull/934): Add `runtime.getDocumentId(`) proposal + + * [timothy] We have an implementation in Safari. + * [oliver] Assuming that the proposal lines up with the API we discussed before, it looks good. + * [carlos] I listed some discussion points in the proposal. If for some reason the browser couldn't provide the documentID, I think it makes sense to throw an error/reject. We may want to accept null or undefined for not having to pass window.self. Currently this aligns with the getFrameId proposal from Tomislav back in the day. + * [rob] Will this work for cross-origin/cross-process IDs? Oh, it's async. That resolves the issue. + * [rob] Sponsoring browser is currently Apple, should it be Safari? + * [timothy] Yes. + * [carlos] I'll update that. + +The next meeting will be on [Thursday, February 26th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=69a0de80,3c0). diff --git a/_minutes/README.md b/_minutes/README.md index c3b0b58f9..43723e37b 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,25 +10,23 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2026-02-12 at 8 AM PST = https://everytimezone.com/?t=698e6980,3c0 - 2026-02-26 at 8 AM PST = https://everytimezone.com/?t=69a0de80,3c0 +- 2026-03-12 at 8 AM PST = https://everytimezone.com/?t=69b35380,3c0 ## Past meetings +* 2026-02-12 ([minutes](2026-02-12-wecg.md)) * 2026-01-29 ([minutes](2026-01-29-wecg.md)) * 2026-01-15 ([minutes](2026-01-15-wecg.md)) * 2025-12-18 ([minutes](2025-12-18-wecg.md)) * 2025-12-04 ([minutes](2025-12-04-wecg.md)) -* 2025-11-20 ([minutes](2025-11-20-wecg.md)) -* 2025-11-14 at TPAC ([minutes](2025-11-14-wecg-tpac.md)) -* 2025-11-13 at TPAC ([minutes](2025-11-13-wecg-tpac.md)) -* 2025-11-10 at TPAC ([minutes](2025-11-10-wecg-tpac.md))
All past meeting notes **2026** +* 2026-02-12 ([minutes](2026-02-12-wecg.md)) * 2026-01-29 ([minutes](2026-01-29-wecg.md)) * 2026-01-15 ([minutes](2026-01-15-wecg.md))