w3c · Rob--W · Mar 12, 2026 · Feb 26, 2026
diff --git a/_minutes/2026-02-26-wecg.md b/_minutes/2026-02-26-wecg.md
@@ -0,0 +1,151 @@
+# WECG Meetings 2026, Public Notes, Feb 26
+
+ * Chair: Simeon Vincent
+ * Scribes: Rob Wu
+
+Time: 8 AM PST = https://everytimezone.com/?t=69a0de80,3c0
+Call-in details: [WebExtensions CG, 26th February 2026](https://www.w3.org/events/meetings/6a0eda89-558c-408d-b83d-5f03b8853c30/20260226T080000/)
+Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)
+
+
+## Agenda: [discussion in #953](https://github.com/w3c/webextensions/issues/953), [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)
+   * [2026 London F2F Sign-up](https://docs.google.com/forms/d/e/1FAIpQLSedMSYmPll5cLMewS-Fn-HI2yD27OxNVzdVClYWDGF5lYcMNQ/viewform) ([coordination](https://github.com/w3c/webextensions/wiki/2026-London-F2F-Coordination), [topic discussion](https://github.com/w3c/webextensions/issues/951))
+ * **Triage** (20 minutes)
+   * [Issue 954](https://github.com/w3c/webextensions/issues/954): Proposal: dom.didPerformAutoFill() (@kiaraarose)
+   * [Issue 955](https://github.com/w3c/webextensions/issues/955): Alert users when an extension is disabled programmatically
+ * **Timely issues** (10 minutes)
+   * [Issue 951](https://github.com/w3c/webextensions/issues/951): Face to Face topic discussion
+     * [Collaborative whiteboard](https://www.tldraw.com/f/S2HPe8jnZaY-PrFlazT5x?d=v0.0.1078.929.page) ([static SVG export](./2026-02-26-whiteboard.svg))
+ * **Open discussion** (25 minutes)
+   * None
+
+
+## Attendees (sign yourself in)
+
+ 1. Rob Wu (Mozilla)
+ 2. Oliver Dunk (Google)
+ 3. Benjamin Bruneau (1Password)
+ 4. Stephen McGruer (Google)
+ 5. Ben Greenberg (Aglide)
+ 6. Christoph Schwering (Google)
+ 7. Kiara Rose (Apple)
+ 8. David Johnson (Apple)
+ 9. Mukul Purohit (Microsoft)
+ 10. Carlos Jeurissen (Jeurissen Apps)
+ 11. Tomislav Jovanovic (Mozilla)
+ 12. Simeon Vincent (unaffiliated)
+ 13. Maxim Topciu (AdGuard)
+ 14. Jordan Spivack (Capital One)
+ 15. Casey Garland (Capital One)
+ 16. Brandon Lucier (1Password)
+
+
+## Meeting notes
+
+Announcement: 2026 WECG Face to Face (London)
+
+ * Sign-up sheet: [2026 London F2F Sign-up](https://docs.google.com/forms/d/e/1FAIpQLSedMSYmPll5cLMewS-Fn-HI2yD27OxNVzdVClYWDGF5lYcMNQ/viewform)
+ * Coordination: https://github.com/w3c/webextensions/wiki/2026-London-F2F-Coordination
+ * [oliver] We are holding a face-to-face meeting in London. Yesterday I have sent an email to those already registered. If you have not, feel free to reach out.
+ * [tomislav] I got a Visa response already.
+ * [rob] Don't forget to apply for an ETA - https://www.gov.uk/eta
+ * [simeon] We will discuss the topics later today at issue 951.
+
+[Issue 954](https://github.com/w3c/webextensions/issues/954): Proposal: dom.didPerformAutoFill()
+
+ * [kiara] Our authentication experience team mentioned that the browser did not know that a field was autofilled by an extension. Proposal to allow extensions to let the browser know that the field was auto-filled.
+ * [oliver] I let the autofill people on our side know about this. Stephen and Christoph on our side.
+ * [david] In Safari, what we would do, is setting the pseudo-selector autofilled so that the styling is applied, and also to not offer to save credentials filled in from another password manager.
+ * [stephen] Stephen, from Chrome's Payments team. Have heard of this topic one hour ago and decided to join. FYI there is an autofill group. Upcoming meeting next Wednesday, March 4, encourage you to join and participate. Apple folks - speak to Ricky on your end.
+   * https://www.w3.org/community/autofill/
+ * [christoph] Extensions in Chrome, UI clashes?
+ * [oliver] On UI clashes, these are still a problem today. Our extension API allows extensions to turn off saving, but that does not disable auto fill, as if we already have an existing password for a site we want to make sure the user knows.
+ * [christoph] Race conditions? Who would win?
+ * [oliver] This API would not help with the UI. But the extension would enable the browser to decide to not show the autofill UI if the extension had filled something.
+ * [david] We also considered just allowing extensions to set the autofill pseudoclass, but felt that it is not that strong of a signal.
+ * [oliver] I wonder if password managers would want to use our styling or their own brand styling. Can anyone from a password manager speak to this or the proposal more generally?
+ * [brandon] An attribute would be nice. We have similar concerns about saving things.
+ * [stephen] Similar thought from the browser perspective (not a formal statement, just quick train of thought). I'm not sure if we want to set Chrome styling on a field that was set by the extension. Users may wonder where the credentials are, when they look for the credentials in the built-in password manager.
+ * [brandon] It would be nice to know if data was filled by other providers, whether a browser or other password managers.
+ * [rob] Would it be preferable to have extensions set field values another way that could enable this kind of signal propagation?
+ * [stephen] There is the autofill event proposal in the CG. There are non-browser providers (e.g. extension). The event might fill the same purpose.
+   * https://github.com/WICG/autofill-event
+ * [stephen] Another thought is whether to tag events as autofill-related, e.g. generated focus events etc, which allows websites (and extensions) to detect autofill.
+ * [oliver] How would sites change in response to the autofill event?
+ * [stephen] Goal is dynamically changing forms. The “autofill” event allows the website to detect that something has changed, and allows them to update the page. It can then also let the browser know it should reattempt autofill after having made some changes.
+ * [oliver] Rob, I think you were suggesting having a special way to provide the browser with data to fill a field. I know sites do some wacky things with elements, like using contenteditable instead of input or directly watching keyboard events to update an internal value.
+ * [rob] Got it. So the expectation is that extensions prefer to have their own secret sauce to fill in credentials in the best way, and just signal to the browser (and other extensions) that some filling has happened on a best-effort basis.
+ * [simeon] Worth mentioning that in this group we've been discussing the desire to add fields to web platform APIs that can only be set in privileged contexts such as in extensions. For example, setting “unstettable” headers in a fetch() call. Might be useful as a way for an extension to signal it performed an autofill in a way that isn't spoofable by a website.
+ * [rob] Sounds like it would be best to have a proposal proceed through the autofill cg and come back to us when there's more direct need for our integration or feedback.
+ * [kiara] Sounds good.
+ * [oliver] I will join the autofill CG meeting.
+ * [kiara] I will join there as well.
+
+[Issue 955](https://github.com/w3c/webextensions/issues/955): Alert users when an extension is disabled programmatically
+
+ * [benjamin] We have had discussions on disable reasons and events around disabling of extensions in the management API. The management API only affects Chrome and Firefox, Safari does not implement it yet. Last year polymorphic extension attacks were raised, where a malicious extension disables an extension. Is there an appetite for a browser-sourced alert that states that an extension was disabled by a specific extension?
+ * [rob] This is a request to add UI in response to an extension disabling another extension, not a new API or similar, correct?
+ * [benjamin] Yes.
+ * [rob] That falls outside the scope of this group; UI is up to the browser. A request to add or remove explicit UI/confirmation in extension API calls would be in-scope however. Still interested in the discussion here.
+ * [oliver] On the Chrome side, the lowest lift would be to add something to the `chrome://extensions/` page. At the same time that would have low visibility. A modal would have be a higher lift, thoughts like interrupting user flow.
+ * [rob] If we want to make an extension API for this, we may want to provide extensions with a way to declare that they should be nosier when another extension takes action.
+ * [tomislav] In Firefox only enterprise policy-installed extensions can disable other add-ons – normal extensions can't manage enabled state of other extensions. Would be a very narrow capability for us.
+ * [rob] That is the current behavior yes. However there is an open bug that received a patch from a contributor that adds support for `management.setEnabled`, gated by user interaction.
+   * https://bugzilla.mozilla.org/show_bug.cgi?id=1282982
+ * [beinjamin] Is the flow Rob mentioned something Google would consider?
+ * [oliver] Can discuss it internally, just not clear on what the use cases are or their prevalence. Need to think through whether adding a dialog is a breaking change that would affect existing extensions.
+ * [rob] Abuse could be countered by including an option to never ask again (in case the user wants to always allow the extension to auto-disable), and by adding clear attribution (who is trying to disable which extension) along with a way to disable and/or report the calling extension (in case it is abusive).
+
+[Issue 951](https://github.com/w3c/webextensions/issues/951): 2026 WECG Face to Face (London) ([whiteboard](https://www.tldraw.com/f/S2HPe8jnZaY-PrFlazT5x?d=v0.0.1078.929.page), [static SVG export](./2026-02-26-whiteboard.svg))
+
+ * [simeon] Topics for F2F? Biggest pain points as extension developer?
+ * [rob] What will happen with the generated whiteboard?
+ * [simeon] Fill in now, lock after meeting.
+ * Topics from [whiteboard](https://www.tldraw.com/f/S2HPe8jnZaY-PrFlazT5x?d=v0.0.1078.929.page) and their votes (related topics are added as sub-bullets, votes from participants were added between parentheses):
+   * Inconsistencies between browsers (5) (sum: 10)
+     * More cross browser testing (3)
+     * Absence of cross-browser written standards (i.e. a more "official" MDN docs) (2)
+     * Tooling - TypeScript types that are meant for Chrome with incorrect types in other browsers (0)
+   *
+   * Secure Storage API (4)
+   *
+   * Intentional and unintentional extension origin identification and exposure to websites / Non-static Extension Origins (3)
+   *
+   * Secure Storage API (4)
+   *
+   * Cross-browser extension linking/mapping (2)
+   *
+   * Sidebar_action/SidePanel consolidation (2) (sum: 3)
+     * Sidebar Toggling (1)
+       Inconsistencies
+       Contextual
+       Sizing
+     * Sidebar focus
+   *
+   * DOM refs between MAIN and ISOLATED worlds (2)
+     * Synchronous data access in content scripts (1)
+   *
+   * Messaging between extension contexts (3)
+     * Extension messaging with documentIds (2)
+   *
+   * "stratosphere" Z-index (Extension specific render layer) (2)
+   *
+   * AI APIs (1) (sum: 6)
+     * WebMCP and Extensions (2)
+     * Agentic Extensions (3)
+   *
+   * DNR (stalled issues, check in on progress) (2)
+   *
+   * Permission upgrades on updates (1)
+     * Permission collapses
+       site blocklist (chrome store)
+   *
+   * Background lifecycle event logging (for debugging) (1)
+
+The next meeting will be on [Thursday, March 12th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=69b35380,384). Daylight saving time changed!