From 8c98824f2b01f0445d931fd80bc178d3951e1fa4 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Tue, 14 Apr 2026 14:37:45 +0200 Subject: [PATCH] Publish minutes of 2026-04-07 - 2026-04-09 F2F meetings in London --- _minutes/2026-04-07-london-f2f.md | 617 +++++++++++++++++++++++++++++ _minutes/2026-04-08-london-f2f.md | 621 ++++++++++++++++++++++++++++++ _minutes/2026-04-09-london-f2f.md | 618 +++++++++++++++++++++++++++++ _minutes/README.md | 7 +- 4 files changed, 1862 insertions(+), 1 deletion(-) create mode 100644 _minutes/2026-04-07-london-f2f.md create mode 100644 _minutes/2026-04-08-london-f2f.md create mode 100644 _minutes/2026-04-09-london-f2f.md diff --git a/_minutes/2026-04-07-london-f2f.md b/_minutes/2026-04-07-london-f2f.md new file mode 100644 index 00000000..ff5a5e66 --- /dev/null +++ b/_minutes/2026-04-07-london-f2f.md @@ -0,0 +1,617 @@ +# 2026 WECG London F2F, Public Notes, Apr 7 + +Tuesday, the first day of the three-day face-to-face meeting in London (announcement: [#951](https://github.com/w3c/webextensions/issues/951)). Agenda: https://github.com/w3c/webextensions/wiki/2026-London-F2F-Coordination + + +## Agenda + + * [Kickoff](#kickoff) + * [Secure Storage API](#secure-storage-api) + * [onDisabled Events](#ondisabled-events) + * [Data persistence](#data-persistence) + * [Cross-browser testing](#cross-browser-testing) + * [Sidebar](#sidebar) + * [Click-jacking Protection](#click-jacking-protection) + * [Triage #0](#triage-0) + * [Issue 898: Add a way to synthesize user gesture on a page as extension](#issue-898-add-a-way-to-synthesize-user-gesture-on-a-page-as-extension) + * [Issue 27: tabs.duplicate() must implement a way to duplicate at a given index and with a given active state](#issue-27-tabsduplicate-must-implement-a-way-to-duplicate-at-a-given-index-and-with-a-given-active-state) + * [Issue 273: Inconsistency: path handling across APIs and browsers](#issue-273-inconsistency-path-handling-across-apis-and-browsers) + * [Issue 1: What to do with the older CG?](#issue-1-what-to-do-with-the-older-cg) + * [Issue 128: Proposal: agree on a unified sidebar API for mv3](#issue-128-proposal-agree-on-a-unified-sidebar-api-for-mv3) + * [Issue 139: Do not outlaw dynamic code](#issue-139-do-not-outlaw-dynamic-code) + * [Issue 616: Content script injection inconsistencies in the sidePanel](#issue-616-content-script-injection-inconsistencies-in-the-sidepanel) + * [Issue 815: Inconsistency: Retrieving closed shadow roots](#issue-815-inconsistency-retrieving-closed-shadow-roots) + * [Issue 112: Add an API to trigger extension update](#issue-112-add-an-api-to-trigger-extension-update) + * [Issue 148: Proposal: allow webRequest with background.persistent: false / SW](#issue-148-proposal-allow-webrequest-with-backgroundpersistent-false--sw) + * [Issue 755: Proposal: about: matching](#issue-755-proposal-about-matching) + + +## Attendees + + * Devlin Cronin (Google Chrome) + * Oliver Dunk (Google Chrome) + * Patrick Kettner (Google Chrome) + * Rob Wu (Mozilla) + * Tomislav Jovanovic (Mozilla) + * Kiara Rose (Apple) + * Carlos Jeurissen (Jeurissen Apps) + * Ben Greenberg (Aglide) + * Jonathan Kingston (DuckDuckGo) + * Dave Vandyke (DuckDuckGo) + * Simeon Vincent (Independent) + * Benjamin Bruneau (1Password) + * Brandon Lucier (1Password) + * Dean Murphy (eyeo) + * Mukul Pirohit (Microsoft) + * Nitisha Rathi (Microsoft) + * Jordan Spivack (Capital One) + * Casey Garland (Capital One) + + +## Notes + + +### Kickoff + + * Intros + * Logistics + + +### Secure Storage API + + * (9:50) + * secureCache proposal: https://github.com/simpleplaces/webextensions/blob/secure-key-cache-revamp/proposals/secure-cache.md ([permalink](https://github.com/simpleplaces/webextensions/blob/42b245f25ebf73959b90e7b4ca104f421b11dbf2/proposals/secure-cache.md)) + * [benjamin] Renamed secureStorage to secureCache for reasons which will be obvious; We would like a secure storage where we can access keychain/biometrics etc in a manner verified by the browser/device. All OSs (macOS, Windows, iOS, Android, except Linux - later) have mechanisms to store, retrieve and remove small amounts of data, requiring user verification and/or timeouts. + * [rob] What about Linux? + * [benjamin] Not a convenient place to store that data. Freedesktop Secure Storage API exists, but capabilities vary. + * [What's the plan for durability on Linux?](https://github.com/simpleplaces/webextensions/blob/42b245f25ebf73959b90e7b4ca104f421b11dbf2/proposals/secure-cache.md#:~:text=What%E2%80%99s%20the%20plan%20for%20durability%20on%20Linux) (section in secure-context.md) + * [oliver] Briefly, what's changed since the last proposal? + * [benjamin] TTL has been integrated. That's the single largest change. + * [oliver] If this data persists across browser sessions, we should note that the data will live until the browser is reopened. + * [benjamin] Makes sense. Key is that it doesn't exist beyond this lifespan from the extension's point of view. + * [devlin] With the secure storage proposal, the key was that data was persistent. This makes no guarantees about durability. What can you not do today with storage.session? + * [benjamin] session API, main issue is that all state is reset. Would be nice if a user returning after a restart does not have to enter their long passphrase. + * [devlin] Guarding against evil maid attack is at odds with desire to store secrets in cleartext. + * [benjamin] Intent is to have something live longer than the session and for that data to live in the secure enclave. TTL should be less than the time to re-auth. + * [devlin] Can we use passkeys for this? + * [rob] That's mentioned in the doc + * [Could a web API like WebAuthn cater for this use case?](https://github.com/simpleplaces/webextensions/blob/42b245f25ebf73959b90e7b4ca104f421b11dbf2/proposals/secure-cache.md#:~:text=Could%20a%20web%20API%20like%20WebAuthn%20cater%20for%20this%20use%20case) (section in secure-context.md) + * [oliver] I recall that 1Password tried to use webauthn, UX is geared towards using a credential and signing in with a credential. The browser dialog that the user sees does not make sense for the context they are expecting. + * [benjamin] Also, large blob storage is called out as not intended for secure data. + * [oliver] A concern in the past was that doing this cross-platform was difficult. Device bound session credentials might be useful here. + * [dave] Why aren't there guarantees for persistence in this new proposal? + * [benjamin] In order to make allowances on systems like Linux where you may or may not be able to access a secure keystore. In that case, you'd fall back to session memory. + * [dave] But you would know that it didn't work? + * [benjamin] Yes, and the getInfo method would provide information about hardware backing. + * [rob] Intent is that the API will always allow you to store, read, delete, falling back to memory-only as needed? + * [benjamin] Correct. + * [nitisha] Would it be secure if each Extension would have their own implementations. + * [devlin] Browser mediates to use system APIs. + * [ben] Would making it persistent be particularly difficult? + * [devlin] Not sure about difficult, but for me it's more desirable. Not clear to me that this proposal offers much beyond storage.session today, and parts can be polyfilled with webauthn. + * [benjamin] Could use storage.session for a fallback case. If we removed the TTL, would that make the proposal more interesting? + * [devlin] No issued with it conceptually, in the original proposal I was concerned about ability to implement this across browsers and platforms. Landscape may have changed by now. + * [oliver] Sounds like you are not opposed to TTL, but want persistence to be an option? + * [devlin] Do not feel too strongly. TTL sounds fine, but without guarantees on durability. + * [benjamin] To be clear, the proposal does allow for an unlimited time to live. + * [oliver] Does durability here refer to the fact that we are relying on system APIs over which we have little control? + * [benjamin] If it weren't durable, it wouldn't be useful. The cache framing foregrounds the idea that you can set a TTL, whereas the storage APIs don't have that concept. Also a hedge against systems that don't have hardware backing. + * [dave] Why not just throw an error if there's no way to store something securely, then you could fall back to session storage. + * [devlin] I'd also prefer that approach. Should be easy enough to write a library to transparently fall back if you want that behavior. + * [ben] Agree with that concern. For a concrete case where persistence is important, E2E encrypted systems that rely on SSO, it's important to trust a device, go through the cryptographic verification flow. + * [oliver] In that case it sounds like you want it to exist for the duration of the extension's lifecycle in the browser. + * [ben] From the user's point of view, they set up the extension once and it remains functional. Particularly important in enterprise, where the user may not be directly involved in the setup. + * [benjamin] How about the question of user verification? Being able to popup up a biometric or pin prompt. Is that an unreasonable ask? + * [devlin] Depends on the operating system. Outside the realm of what browser directly control. + * [oliver] I think keychain and windows hello allow you to require user verification to retrieve data. That should be something the browser can pass through to the underlying system. + * [kiara] Should be possible on the Apple side. + * [benjamin] Important for us as well. + * [ben] What's the use case for the browser not return the data after the TLL, as opposed to returning the data with the TLL set. + * [benjamin] Contract with the user. If you tell the user “I'm storing this for 14 days”, we can't disregard that and do whatever we want after that period ends. + * [oliver] To be more precise, this helps prevent an evil maid attack where an attacker could run code in the JavaScript console to retrieve the secret. + * [devlin] Sounds like it's feasible on the Safari side. Firefox? + * [rob] If technically feasible, don't have immediate objections. + * [rob] I do wonder, if UX is the primary objection against webauthn, can we see what it takes to make webauthn a good fit for the use cases, instead of reinventing parts of the webauthn API for the new API. + * [devlin] UX is outside our purview. I'd want to do something beyond webauthn. + * [ben] Certain enterprises ban the use of webauthn, so using those systems may be problematic. + * [devlin] Why do they do that? + * [ben] I don't know. I think it's about normalizing how secrets are persisted. + * [devlin] If there are some valid reasons why enterprises disable webauthn, then we may also need a way for them to disable this feature as well. + * [tomislav] Is that enforced in enterprise policies? + * [ben] Not sure. + * [benjamin] Where does this fit in permissions? Would this require a warning or is in-context grant sufficient? + * [devlin] Non-binding intuition is a permission but without warning. And visibly show the context when prompting. + * [jonathan] Interested in exploring the feasibility of device-bound credentials instead of this API. + * [devlin] Summarizing, no browsers said no to this. And to explore the storage angle more than the caching one. + * [kiara] Agreed. + + +### onDisabled Events + + * (10:30) + * Related issues + * [Issue 138](https://github.com/w3c/webextensions/issues/138): Proposal: let content scripts listen for event to detect when the extension is unloaded (for various reasons) + * [Issue 353](https://github.com/w3c/webextensions/issues/353): Support onEnabled event when the extension from disabled state to enabled state + * [Issue 836](https://github.com/w3c/webextensions/issues/836): Allow extensions to track their own disable/uninstall events + * [Issue 970](https://github.com/w3c/webextensions/issues/970): Should disabled extensions have their runtime.setUninstallURL opened on uninstall? + * [simeon] This topic was requested when we asked for topics + * [casey] Any improvements to getting insights into uninstalled or disabled would help us and our users. + * [carlos] You are thinking of the following issue, right: [Issue 970](https://github.com/w3c/webextensions/issues/970): Should disabled extensions have their runtime.setUninstallURL opened on uninstall? As mentioned in the issue setUninstallURL currently does not work in Firefox for disabled extensions. + * [] Why is Safari against setUninstallURL? + * [casey] It was explained before that uninstallation in safari is a soft delete, so “uninstall” was nondeterministic. + * [kiara] I can look into that. + * [dave] What would disabled do? I can imagine opening the uninstall URL or similar could be annoying. + * [devlin] I don't think we'd want a disable URL type thing. I see a couple motivations for these types of events. onEnabled, onDisabled events are useful especially for content scripts, as we can't unload them. This allows them to react to that event. + * [dave] Would disabled have a distinction between a user doing it vs a browser doing it? + * [devlin] Would want to flesh that out. For content scripts, I don't know if we'd want the differentiation between disabled and uninstalled. Could leak info the user didn't intend to expose. + * [dave] Say DuckDuckGo changes search, if the extension is disabled, I guess we'd have to assume the user did it. Could be some UX improvement if we know the user explicitly intended to do it. + * [devlin] There are something like 25 disabled reasons in Chrome. We wouldn't want to surface all of them. The main goal is to surface them from running. + * [brandon] Also called out polymorphic attacks, right now we don't know if 1Password is disabled by another extension. + * [benjamin] In Firefox mitigated by extensions not being able to disable other extensions, but in Chrome would like to know that. + * [oliver] Patrick, you were working on some UI changes if an extension disabled another. + * [patrick] Yep. + * [devlin] Personally not a fan of the management permission. + * [] Rob, did you mention the desire to have a user gesture in previous discussions? + * [rob] Yes. However, when I asked for use cases for disabling extensions, the use cases involve unattended scenarios, where extensions disable based on times or website visits, where putting up a prompt every time may be too disruptive. Now we are thinking of allowing extensions to disable other extensions through an enterprise policy or hidden pref. Not to enable it by default, as this is mostly a feature for power users. + * [dave] Would we be allowed to display a message in a page when the extension is disabled? + * [devlin] We'd probably want to discourage that. If the user chose to turn something off, there are a lot of dark patterns around “you turned X off and are now at risk”. + * [carlos] For content scripts we merged [a proposal for runtime.onInvalidated](https://github.com/w3c/webextensions/blob/main/proposals/runtime_on_invalidated.md). Any progress there since then? + * [oliver] Not aware of anyone working on that. + * [devlin] We've touched on a number of things. 1) Having better uninstall tracking across browsers. 2) For content scripts, having a signal for when the extension is removed for any reason. (onInvalidated or onUnloaded) 3) Extensions disabling other extensions is painful. That's probably not something we want to solve with new events. More likely that we should address this through UI changes to verify user intent. We'd probably tackle that outside of + * [mukul] What are the use cases for extensions disabling other extensions? + * [devlin] Multiple extensions installed that conflict, such as ad blockers. Password managers conflicting. + * [patrick] In the Education space, proctoring extensions disabling other extensions and locking down the device. + * [jonathan] Stores expect you to have a narrow use case. When an extension does multiple things, we could split it up in separate extensions and install optional features via one management extension. + * [rob] Extensions cannot install other extensions. + * [simeon] Power user tools. Switching between work modes and changing the set of running extensions. + * [devlin] Going back, the use cases are uninstall tracking, content script signaling, and protecting users from malicious extensions. + * [dave] Could a content script make a web request to detect disabling? + * [devlin] I'd discourage that. + * [patrick] In the Chrome Web Store developer dashboard, we expose a raw number of enabled or disabled extensions. + * [oliver] Right now you either don't know when a user has uninstalled your extension or you have to set an uninstall URL, which is a very heavy weight solution. + * [devlin] It could close itself. I think the visible flash of a tab opening may have been the motivation for that behavior. I'd be open to considering an event. + * + * [devlin] I'm torn about ondisabled. I don't think extensions will generally want that info. + * [patrick] PMs are typically interested in statistics, e.g. observing disable rates after a change goes live. + * [devlin] For raw count of disables, that's visible through the dashboard. Ideally you'd be able to set up alerting (I realize you can't). + * [devlin] Trepidation around ondisabled ping is that I don't think we'd want to send it in all cases when an extension is disabled. Malware, enterprise policies, custodial approval on Chromebooks, reinstall/repair, etc. There are many reasons that we may not want to expose or they would just be noise for developers. My intuition is that if we only gave you a disable ping when the user disabled it, I'm not sure how you leverage that data. + * [casey] Could get version info. + * [patrick] It's not about an individual user, it's about change in scale. + * [devlin] If we were more okay with saying that disable is only in response to a user action, only some user actions, non-exhaustive list of reasons, etc. If we can have all those caveats, I'm more comfortable with this. + * [rob] Is the uninstall url persisted in Chrome? In Firefox we don't persist. + * [oliver] Would you consider that a bug? + * [rob] Not clear what the behavior should be. We don't do anything when an extension is disabled by a blocklist. When disabled by a user, may also not want to open the uninstall URL. + * [devlin] If it's disabled and the user uninstalls it, I don't think we'd want to open the uninstall URL, but I'd be amenable to a ping. + * [dave] We'd want to be able to set some parameters to measure retention. + * [devlin] Would want to talk more about that. Having extension version makes sense, but storing arbitrary user data is more concerning. + * [dave] Would want to do something similar to what we do with setUninstallUrl. + * [oliver] If we're worried about sending data, it should be static in the manifest. If we allow setting a URL programmatically, we have to be comfortable with arbitrary data. + * [dave] If it's already acceptable in the uninstall URL, why is it concerning for a ping URL? + * [rob] Do we have to solve this at the API level? + * [oliver] We already expose percentage of disable in the CWS dashboard. If we have a new signal, where do we expose that? + * [rob] If extension devs are interested in tracking retention, they don't necessarily have to do it at the ping level. The browser could provide services that collect that data for the developer + * [patrick] Stores are out of scope, right? + * [devlin] Store data drifts. + * [dave] People are going to do it if you provide the event. + * [rob] Might make sense to set in the manifest, which would also enable the request to be sent from someplace other than the user's browser. + * [devlin] Placeholders in the string + * [rob] If we implemented this in Firefox, I'd want a preference (option) to turn this off. + * [johnathan] If there's a content script signal, developers will do what they want with it which may include tracking. + * [carlos] Depends on whether the invalidated event includes a reason. Would Safari be supportive for an uninstallPing considering Safari was not in favor of setUninstallURL before + * [kiara] I think the hesitancy on setUninstallURL was not wanting extensions to show something immediately after removal. Seemed like an annoyance. Would we have a different url for removal ping? + * [devlin] Yes. Again, would want to set expectations that this is for most user disable reasons. Not when disabled by the file disappearing from the filesystem, or when disabled by other extensions. + * [nitisha] We have feedback from users saying that uninstallUrl is annoying. + * [rob] Some extensions open a new tab on update, unrelated to uninstallURL. + * [carlos] Just tested, in Firefox when you uninstall it will open the uninstallUrl in a new tab in the current window, but does not focus that tab. + * [rob] When an extension is disabled, then uninstalled, does that open the uninstall URL. + * [devlin] uninstallUrl is not opened on disable in Chrome. It's opened when uninstalled except when on the blocklist. + * [oliver] Clarify being blocklisted? + * [rob] Disabled for being malware, roughly? + * [devlin] Yes. Not for policy reasons. + * [kiara] What about when the extension is uninstalled while the browser isn't running? That can happen in Safari. + * [devlin] Chromium won't handle removal until the next time it runs. + * [rob] Devlin, previously you mentioned that you don't want to send a disable ping when an extension is disabled by another extension. But one of the use cases mentioned before is for extensions to detect when they are being disabled by another extension. Could you elaborate? + * [devlin] Prefer that issue to solved differently than through a disable ping. + * [devlin] Action items: setUninstallUrl, is there appetite for browsers to align on behavior? + * [tomislav] Yep. + * [carlos] Adding it to Safari would allow any app which has an extension to open a page when it gets uninstalled, even if disabled. + * [kiara] Don't know that we'd ever support it. + * [dave] Could Safari make the request without opening a tab? + * [rob] That's the ping + * [devlin] Let's come back to that. + * [devlin] Uninstall ping? + * [kiara] I'll circle back. + * [rob] Need to discuss with the team first, but tentatively okay. + * [devlin] For disabled ping, for some set of disabled reasons, general appetite? + * [nitisha] For a subset of user initiated. + * [kiara] Same, if we approve of an uninstall ping, it would also apply to disable. + * [rob] Same. + * [devlin] For extensions removing extensions, that's something we'll need. + * [oliver] Still want to see if we can align on setUninstallURL behavior. + * [devlin] We persist it until the extension is removed. + * [oliver] Maybe we could add that as a topic: we're inconsistent now, but would like to have a decision tree for the persistence of data. + * [rob] Could discuss this during the meeting on Thursday. + * [oliver] Would like a broader discussion about data retention. + * [dave] If we had the pings, the Firefox approach makes more sense. + * [rob] Depends on the use case. + * [carlos] Rob, would you be supportive of opening the page if an extension is disabled and then uninstalled? + * [rob] That would require us to persist the URL. + * [rob] How many devs here use the uninstall url? + * (responses: DuckDuckGo, 1Password, Jeurissen Apps, Adblock Plus; for measuring retention and surveys) + * [rob] Do we need to make the uninstall URL dynamic or can it be set in the manifest. + * [dave] As long as we can set data in the URL. + * [rob] Ok, so it needs to be dynamic. + * [johnathan] Are placeholders used elsewhere? + * [devlin] Messages. May also be relevant for internationalization. + * + * [oliver] Should we add a new clearUninstallURL method to allow extensions to clear the uninstall URL? + * [rob] Don't think that we need a new method for this. Firefox already clears the URL when set to null or an empty string. + * + * Action Items + * setUninstallURL() + * Implemented in Chrome / Edge + * Differences in Firefox + * Unlikely (but not impossible) for Safari + * **Action Item: Chrome and Firefox to potentially align** + * A new uninstall ping + * Chrome supportive + * Firefox supportive + * Safari not supportive + * Edge supportive + * **Action Item: Browsers to ask, circle back, come up with concrete proposal** + * A new on-disable ping, sent only for a subset of reasons (likely just user action) + * Chrome supportive + * Firefox supportive + * Safari not supportive + * Edge supportive + * **Action Item: Browsers to ask, circle back, come up with concrete proposal** + * Content-script visible event for extensions being disabled, uninstalled + * Chrome supportive + * Firefox supportive + * Safari likely supportive + * Edge supportive + * **Action Item: Chrome to separately work on extensions-disabling-other-extensions issues** + * **Action Item: Chrome should add a way to clear the uninstall URL** + * Chrome and Firefox should align on setUninstallUrl(null) removing the uninstall URL. + + +### Data persistence + + * [oliver] Jackie put together a table showing the interaction between different ways extension data is retained, a while back. + * https://github.com/w3c/webextensions/blob/main/memo/persistence-of-states.md ([permalink](https://github.com/w3c/webextensions/blob/96a105bced381aa5705f96505c35f53ede1a597b/memo/persistence-of-states.md#api-list)) + * [oliver] Based on the cases I am aware of, it makes sense to default to persist until an extension updates, or shorter (until browser restart) in some cases. Storage is an exception (persist indefinitely) + * [devlin] Are you saying we should not persist most things across extension updates? + * [oliver] For many things, yes. Storage persists, but things like dynamic rules do not. + * [dave] Is it bad to retain dynamic rule? + * [oliver] Don't have strong feelings other than wanting to get consensus. Argument in the past is that the dynamic rules are directly tied to static rules. + * [devlin] DNR is a special case. We knew dynamic rules are used as a patch for static rules. + * [rob] Their association is only tied to the use case targeted during design. The `declarativeNetRequest.updateDynamicRules` API can be used independently of static rules. + * [oliver] Another example is alarms, currently inconsistent between browsers. I think that it makes sense for alarms to be cleared on extension update. + * [devlin] I'm a little worried that clearing everything on update will force developers to duplicate all of their stored data in Storage in order to re-add it. + * [oliver] What would we want to persist across updates? + * [devlin] I think alarms are more likely to want to be persisted. Broadly speaking, anything that is truly dynamic in nature would want to be persisted across updates. + * [oliver] Don't have a clear picture of common use cases for alarms. I think most of them are internal use. + * [devlin] Generic rule is my stuff is different than your stuff for the same installed extension. + * [oliver] Counter argument: ad blockers using dynamic rules to store user custom rules. It's in favor of them persisting, but we don't currently retain them. + * [devlin] Might make sense to have dynamic rules that are patches get cleared, and have dynamic rules that are user settings persist. + * [tomislav] To generalize from DNR is special, what's special about it? Part of the rules are defined from the manifest. + * [devlin] What's special about it is the expectation that dynamic rules are expected to static rules. + * [rob] Only for the ad blocker use case. + * [tomislav] Because it's already tied to the manifest, it can change between versions. Static rules themselves can change. Makes sense to change due to that close association. By extension, other rules defined in the manifest may make sense to clear associated data. + * [oliver] `action.setIcon` can be set in the manifest. In that case we'd clear it across the update. + * [rob] We don't persist that, don't want to write big blobs of image data to disk every time it is called. + * [devlin] Cleared across sessions currently. Deliberate change made in MV3. We realized everyone using dynamic icons were being set against the currently open pages. + * [oliver] setUninstallUrl isn't currently controlled by the manifest. Would that persist across extension updates? + * [devlin] For things like that, I don't think it matters. + * [rob] It matters - it is surprising for an extension (version) that does not call setUninstallURL to have a page opened in a new version. + * [oliver] Matters for developers to know in order to set it. + * [devlin] I think they'll just call it. + * [oliver] The documented behavior should be well defined. + * [devlin] I think more interesting cases are ones where values are different per user. That's data you'd inherently want to persist across updates. + * [oliver] So you think setUninstallURL should…? + * [devlin] Don't care about that one specifically. There's no harm in calling it every time. Context menus maybe. + * [rob] So you're thinking about it from the point of view of how often you write it? + * [devlin] No, about how data is being set. + * [rob] Back to uninstall example, if we persist across extension updates, if an extension had ever called it in the past, they need to include it in every call from now on to set it to null. If you made a mistake in the past about a decision to use the API, you have to account for that forever by unconditionally having to clear the uninstall URL on update. + * [dave] For uinstallURL you just overwrite it with abandon because you might as well. You can't even read it back. + * [oliver] Agree with Rob's stance that if you set it in the past, you have to re-call setUninstallUrl. + * [dave] If you set the URL with parameters to measure retention, you're calling it quite often to update those values. Maybe even call it too often, since you can't check what it is. + * [rob] Didn't mean to discuss uninstall specifically, just provide an example of why you might not want to persist. Like Dave said, the extension already calls the API frequently, so even if the persistence is limited, it would not break the expected outcome (uninstall URL to be set). + * [carlos] As a developer, you also have a more synchronous baseline across extension updates. + * [dave] Personally, I find it especially confusing since the background goes away. If I'm trying to reason about the state of the extension, it's confusing if an alarm might persist, but a variable in the background changes every time the service worker restarts. I could find myself accidentally re-creating the same alarm. + * [ben] For the service worker, it would be memory and message registration. That would need to be reinitialized, but you can assume the container of the extension persists. + * [dave] It's another variable to keep track of. + * [carlos] What are we trying to achieve? + * [oliver] Would like to keep talking through use cases to see if there are common patterns. + * [ben] For general code complexity and maintenance, prefer to be able to run a setup state to prepare the environment. If we can minimize inconsistency, that would be ideal. Session-only retention in general would probably be best. + * [oliver] I think that makes sense. The cleaner the state is, the easier it is to maintain. But could also be a pain to set up. + * [devlin] I think most things we wouldn't want to be session-only because ideally you wouldn't need to spin up the extension on session start. Starting up a browser is costly, the more work you have to do then the longer you delay the browser being ready. + * [rob] For patterns, I see some weakness in things like setUninstallUrl and storage.StorageArea.setAccessLevel. Most common use case is immediately after installation, these APIs are called to configure their value. There is a window between extension install/update and startup where the extension has not had the opportunity to call the necessary API yet. E.g. if an extension stores sensitive data in storage.local, may not be able to call setAccessLevel at the right time. It may be preferable to declare that kind of thing in the manifest. + * [oliver] Seems reasonable. + * [devlin] Not opposed to it. Not sure how high of a priority it would be. + * [oliver] Devlin, you mentioned context menus might be an interesting one. Any more thoughts? + * [devlin] No. Strikes me that we should be persisting context menus at least for an extension version. In this case, I don't have enough anecdata to say how often an extension is setting a per-user custom context menu. + * [patrick] I expect that it's extraordinarily rare for users to have distinct context menus. + * [oliver] Sounds like we're aligned that context menus don't currently persist across extension updates, based on Jackie's table. In the past, we had a discussion around alarms for exposing a persistent flag. If enabled, it would only retain a given extension version. Are we okay with that? + * [rob] I think we agreed to have a flag. I don't know if there was agreement on what to do by default. + * [oliver] I think we agreed not to align for backwards compatibility reasons. Not sure about when retention is set, do we retain across updates? + * [rob] No. + * [oliver] Devlin, does that sound reasonable? + * <discussion about alarms carrying over, manifest flag, etc.> + * [rob] Not necessarily about alarms, but a general pattern. If we don't persist across updates by default, what do we do if an extension wants to retain that data across updates when the developer doesn't want to detail with the retention. + * [devlin] I think in general they'd store it and re-add it. + * [oliver] Would it make sense to have a manifest key? If not, does it make sense to have it retained in a given manifest version? If not, + * [devlin] Hesitant about forcing things into manifest keys. + * [oliver] Not the intent. Consider it, but … Are there cases where a manifest key would make sense but you think we shouldn't use one? + * [devlin] Don't want to push things into manifest keys unnecessarily. Context menus don't need to be there. + * [oliver] What's the disadvantage of having it in the manifest? + * [devlin] Big manifest. + * [rob] In terms of advantages, declaring in the manifest would allow automatic localization. + * [oliver] Would better phrasing be that you can statically declare things? E.g. could be a separate file linked from the manifest. + * [patrick] How would you define a callback for the context menu? + * [devlin] Used to be a callback in persistent background pages, but you'd just use the general event. + * [oliver] I think the guidance would be that you should consider if something can be declared statically, if not it can't be in the manifest. I think this is something we should document in the community group and use as guidance going forward, not changing existing API. + * [carlos] We can add it to the proposal docs to have an additional heading about “should this API persist”. Seems like a good process improvement. + * [devlin] Something we already have to deal with, but not sure I want to do more, is if you have both static and dynamic values, it's difficult to know what the extension will do at runtime. Many of these things are things you'd want to configure. UninstallURL can be in the manifest, as can be setAccessLevel. Set Alarms shouldn't have to be statically declared. + * [oliver] If we caveat it with “if there are enough use cases where it needs to be dynamic, don't include it in the manifest.” + * [devlin] Not opposed to saying “if it should never change, make it static. If it needs to change, make it dynamic.” + * [oliver] Seems like we're aligned on some high level guidance. I can draft that. + * [rob] If something is declared in the manifest and can be overridden, what do we do when the value changes in the manifest on update? Don't have to answer now, but relevant for the guidelines. + * [oliver] Dynamic content scripts are cleared on update, dynamic rules are cleared on update. + * [devlin] Slightly different, those aren't overriding everything. + * [dave] What about static rulesets that are enabled/disabled. + * [devlin] That's a good example. If we exposed enable/disable content scripts, that would be similar. + * [oliver] How are disabled static ruleset handled? + * [rob] Not sure how it's handled in Chrome, but in Firefox it's not retained, consistent with static/dynamic rules. + * [oliver] If you have the same static rulesets across an update, you probably don't want to change the enabled state across updates. That could be a user setting. + * [oliver] For alarms, we're sticking with it only retaining across sessions if the flag is set. + * [devlin] In Jackie's table, he calls out retaining data across enable/disable. Do we ever expect to use that? + * [dave] As a user, I expect it to come back. + * [devlin] There are a bunch of things that are only retained across a session, + * [rob] In some cases data is stored in an on-disk cache. That cache is cleared on extension update. For some things, I agree that it shouldn't behave differently. + * [devlin] Is there any set of things that you would expect to be cleared on disable/enable that aren't cleared across browser sessions? + * [rob] There's a distinction in the implementation where disable/enable is more similar to updating an extension. + * [ben] Would be helpful if we could standardize the behavior so it could be classified as a bug. + * [tomislav] I think we can consider that a bug in Firefox. In all cases, except context menu creation, B and D are the same. + * [rob] In Firefox B and D are also the same for context menu; it was a bug we fixed (​​https://bugzilla.mozilla.org/show_bug.cgi?id=1771328) + * [devlin] Sounds like we can tentatively say B and D can be collapsed. + * [simeon] For the notes, everywhere I've written “on update”, it means extension update, not browser update. + * [ben] Is there a difference between them? + * [devlin] They are completely independent, at least for Chrome. + * [ben] If the browser updates but the extension doesn't, what happens? + * [rob] We fire runtime.onInstalled. It's fired because when the browser's internal data structures change, we need to reinitialize. + * **Action Item**: Rob to update table to drop D (context menu bug got fixed). + + +### Cross-browser testing + + * [kiara] I'll be giving an overview of how to contribute. + * [kiara] WPT is short for Web Platform Test. Prompts browser interoperability, helps ensure consistent behavior across browsers. Results are surfaced on wpt.fyi for cross-browser comparisons. + * [kiara] Should we cover extensions in WPT? Absolutely. They're supported in all major browsers, but inconsistencies exist. Main way we detect these inconsistencies is developers raising these issues on our bug trackers and in the WECG. Tests also help ensure behavior doesn't regress. + * [kiara] Current status of extension tests in WPT: we have three tests currently running in Safari Tech Preview and Firefox Nightly. Once Chrome adds support for the browser global I expect these will pass as well. + * https://github.com/web-platform-tests/wpt/tree/master/web-extensions + * [kiara] To contribute, for the WPT repo, set up your device to run tests (just takes a few commands). A few queries: currently only runs on Firefox Nightly, but work in progress to fix that. Runs in both regular and Tech Preview safari. /web-extensions is the test folder where they're all set. + * [kiara] Live demo time! + * [dave] What can tests control? Can you open the popup? + * [tomislav] Not yet. Initially focusing on things that only require APIs to test, but plan to support that kind of interaction in the future. There are special parts of the WPT test harness to hook up those kinds of interactions. + * [kiara] The goal is to have full automation, but didn't want to block on that. + * [kiara] `.extension.js` suffix in file, adds our wrapper to create some boilerplate code. The `resources/` directory has sub-directories for each extension namespace. + * [kiara] Looking at `storage`, the `background.js` file is the driver of the test. + * [kiara] Let's look at `browser.storage.extension.js`. That calls `runTestsWithExtension()` with the path to the extension we're testing. In the `web-extensions-helper.js` file in WebDriver, we have the implementation of `runTestsWithExtension()`, which manages and runs the test. + * [kiara] To create a new test, in `web-extensions/resources/storage/background.js` we call `browser.test.runTests` with a list of functions. The `background.js` is loaded from `manifest.json`. + * [rob] The `manifest.json` file lists `background.js` at `scripts` and `service_worker`. Both are needed; Firefox supports `scripts` only, Chrome supports `service_worker` only. Since Firefox 121 and Chrome 121 both browsers accept manifests containing both. + * [rob] What's the significance of the name in the manifest file? + * [kiara] Consistency. Just lets you know what test is running. Not used by WPT. + * [tomislav] WPT only knows and works with file names. + * [dave] So you can only have one manifest for all browsers? + * [tomislav] Currently, that's correct. We could configure the harness to allow loading of different extensions per browser, but we're targeting consistency so we don't want that. + * [kiara] in `storage/background.js` I create a data object to test storage and retrieval of various data types. In the test we set that data with `browser.storate.local.set(data)`. + * [kiara] Let's check to verify the number of returned keys is correct, that the data types are correct, etc. + * [kiara] We can then run it with `./wpt run firefox web-extensions/browser.storage.extension.js --no-headless` + * [dave] Ah, so you could test DNR rules across browsers. + * [tomislav] Yes, there are a set of special domains you can use for testing in WPT. + * [dave] For DNR API, there are browser tests in Chrome that you may be able to port over + * [tomislav] That's the goal. + * [dave] Is this coming to Chrome? + * [devlin] Yes. + * [tomislav] For Firefox, we're currently Nightly-only. We're waiting to hear from Chrome folks if any changes are necessary. + * [devlin] Currently waiting for browser global to land and we ended to make some changes to the browser.test namespace. We currently have over 10,000 tests and we're not going to port all of those. Need to figure out how to balance between the two runners. + * [kiara] I'd propose that any new APIs being proposed or specified also include tests. + * [rob] Typical development flow In Firefox is to include a test in the repo and then a bot creates a PR to upstream that. Is that the same in Safari? + * [kiara] Yes. + * [simeon] Each browser has a way of upstreaming tests. What about non-browser folks? + * [Dean] Does the test suite cover mobile Safari? + * [kiara] No, currently only covers desktop Safari. + * + * [patrick] + * [kiara] Don't know if there are tests + * [johnathan] For the HTML spec, I think they just ask for conformance across vendors. + * [ben] How do we know what the test should be without the spec? + * [kiara] Could work on the spec in parallel. + * [ben] Can tests be committed without passing? + * [tomislav] Yes. + * (...) + * [rob] So even if someone were to submit a PR with a nice set of tests that pass across browsers, would we not merge it until an accompanying spec is available? + * [patrick] Yes. + * [benjamin] For folks that aren't affiliated that want to contribute, you mentioned upstreaming. Is there a way to know what tests might be coming to make sure that we don't do duplicative work? + * [tomislav] I'd suggest opening an issue on this group's repo to discuss. + * [rob] I'd also suggest going to chat and asking. Likely no one is working on it. + * [benjamin] I was asking in case there are many tests incoming. + * [rob] Tests are upstreamed by the bot when someone authors it in the browser-specific repo. Someone has to write it (and get it reviewed), so it would not appear out of thin air. + * [tomislav] Bot upstream happens every couple of days. + * [oliver] If you're working on implementing a feature in a browser, would you work on WPT tests in parallel? + * [tomislav] I believe that's highly encouraged. For things like DOM, I think that's essentially required. + * [oliver] As someone working at Google, would I make all of my changes through Chromium or land them in the WPT repo? + * [tomislav] Whichever works best for you. Usually the way I see people working on web platform work is to land changes (browser implementation and WPT tests) in parallel in the same repo. Generally, let's practice the way we want to work. + * [carlos] Tests currently include getURL, but we don't have a spec for that. + * [kiara] Yeah, that was just to get something out the door. + * [carlos] I added a test for `runtime.getVersion`, please review. I have merge requests on both Firefox and WPT. + * https://github.com/web-platform-tests/wpt/pull/56993 + + +### Sidebar + + * [Issue 128](https://github.com/w3c/webextensions/issues/128): Proposal: agree on a unified sidebar API for mv3 + * [simeon] In the past we have discussed how to proceed with unifying sidepanel and sidebar_action, to ultimately work towards unifying them in one sidebar API. + * [kiara] At TPAC I believe in a hallway chat we planned to sit down and do some planning on how to resolve the inconsistencies in sidebar. + * https://github.com/w3c/webextensions/blob/main/_minutes/2025-11-14-wecg-tpac.md#sidebar-alignment + * [simeon] Kiara as the main point of contact. + * [carlos] In addition to general runtime API unification, should also talk about the manifest file. Permission, key, etc. Should decide on whether we can jointly ship or + * [dave] Recently experimented and observed that you can open the sidebar from a content script in Chrome but not in Firefox. + * [rob] Chrome requires a user gesture and curries the gesture from a content script. + * [dave] Other thing I ran into is I wanted to have the sidepanel show an external web page, but had to iframe it. + * [carlos] There's another issue in the group about relieving x-frame options in extension iframes. + * [rob] Good topic for this week, also including expectations about partitioning etc, since Patrick is also here (with context from Chrome's mimeHandlers API in development). + + +### Click-jacking Protection + + * [benjamin] Briefly, in the past we've discussed having a top level z-index stack for extensions. Within that it would be first come first serve. 1Password considers this a great solution for a couple of issues, not the least of which is that in our testing every other approach can be circumvented. + * [rob] Is this related to that relatively recent disclosure and talk affecting multiple password managers? + * https://marektoth.com/blog/dom-based-extension-clickjacking/ + * [benjamin] Yes, a DefCon talk. + * [rob] I also audited a password manager extension and found defects in their implementation. I believe that was partially because of browser limitations that extensions need to work around, and then the extension author is unaware of ways to bypass their work-around. + * [benjamin] As long as we're all fighting in the main world, we're scrabbling over the same stack. + * [oliver] I mentioned over lunch – this is very work in progress and will not necessarily land – but we're experimenting with an API that would allow content scripts to pin content to the top of the top layer. We have a patch for, but haven't had larger discussions on it. Still need to see if we could land this behind a feature flag. + * [tomislav] What layer is this? + * [oliver] It's using the top layer on the web. + * [mukul] Could there be multiple elements in this space? + * [oliver] The state of the patch is that only a single element can have this. + * [rob] Does it cover the document or can you click through? + * [oliver] I assume this is the same as using the popover stack. + * [rob] That was indeed going to be my next question, how does it with popovers? + * [oliver] The page can trigger a popover, but it would render underneath the extension's panel. + * [simeon] In the past I think we wanted to go to the CSS working group to talk about having an extension layer on top of everything. Is that still the plan? + * [oliver] I think we need to talk more about this before we go to them. + * [dave] Why can't extension use a stylesheet to achieve the top index? + * [rob] There are many ways for the web page to get on top. + * [oliver] z-index has a maximum, and the only way to get on top is to repeatedly append to the document. + * [rob] Can a web page observe an extension's element? If so, what stops the page from putting something on top of it? + * [benjamin] You mean they'd go and find the element and insert a last child? + * [rob] Yes. + * [oliver] There's some level of assumption of good faith here. This is one of the really hard points that's come up internally. Traditionally we've tried to push for these kinds of capabilities to prevent click jacking, but the desire to draw on top seems to be more about drawing UI on top. + * [brandon] We don't actually care about being on top, we care about not getting input events when something else is showing on top. + * [benjamin] We've looked into using intersection observers, but those experiments effectively destroyed the user experience. + * [oliver] Would be helpful to see those experiments. The permissions API is being implemented with intersection observers. + * [tomislav] Is that standards track? + * [benjamin] Ideally we want an API that we all have some degree of confidence in rather than everyone trying to implement their own. + * [brandon] Also concerned about performance. + * [benjamin] Difficult to do anything that even approaches feeling right. + * [brandon] Action items here: we ended to get examples together. Are you also continuing to investigate on your side? + * [oliver] Yes. + * [jonathan] Some prior conversation in this space is around input elements, how the browser handles autocomplete. Could that help address things? + * [benjamin] Branding, tagging the right elements, there are multiple other concerns with trying to rely on browser UI. There's also an autofill working group that's discussing some of these concerns. If that were to become a robust system, maybe we could bypass a lot of these concerns. But that's dependent on how that rolls out and currently that's highly speculative. + * [jonathan] One of the nice properties of this is that it is in the DOM, so you can use normal positioning and such, but that also doesn't give you all the security properties you want. + * [rob] Sounds like you want to detect if something is on top. What was wrong with intersection observer? + * [benjamin] Significant performance concerns. It's a literal moving target. + * [brandon] Partial overlay is also a concern. + * [rob] That reminds me, one of the attacks is to make the body transparent and to render a fake UI with a background image, to trick the user into clicking on extension UI in the page. Does your prototype cover that scenario Oliver? + * [oliver] We don't do anything special with that. + * [tomislav] Mozilla wasn't initially supportive of the Page Embedded Permission Control (PEPC) proposal. [Mozilla standard position 908](https://github.com/mozilla/standards-positions/issues/908). That links to the updated proposal, which isn't resolved. + * [oliver] To be clear, there's no dependency on the implementation of that element. The way that spec is defined, every permissions element has an internal intersection observer. It's as interesting as possible prior art and for discussion on whether or not our use case is addressed. + * [rob] What are the next steps? + * [oliver] We can keep talking about top layer change and see if that's something we can make available for developers to experiment with. + * [simeon] Seems like having the element exposed in DOM is an inherent limitation here. As long as it's integrated into the page it seems like we don't get the security guarantees we're after. + * [tomislav] I believe Timothy had an idea with using something similar to DevTools' approach to displaying content on top of everything. + * [simeon] I think that might be a bit of a special case. In previous conversations, Devlin expressed concern about having an extension render layer on top of everything. In DevTools, that only happens in select cases where the user has intentionally invoked DevTools. It's not every page the user has open at all times, which it would be for an extension solution. + * [rob] What are you (1Password) painting? + * [brandon] The icon in the input field, the autofill rectangle containing the iframe. + * [rob] If the feature we were implementing was a visual only approach, that would have less complexity than with interaction. + * [simeon] Could we do something like have a special browser.dom method to inject an iframe in the page and restrict the main world from modifying the iframe. + * [devlin] With modern CSS I expect you can't prevent the page from tampering with the iframe. + * + * [tomislav] We'd have to invent a web boundary to accomplish something like that. + * [rob] In terms of what can be feasibly implemented, I can imagine allowing extensions to render content (like an iframe) on top of the top level document, without the page seeing that iframe element. It comes with constraints: it captures clicks which are not forwarded to the webpage underneath. Also raises questions on accessibility (what should tab index do). Maybe try experimenting with `action.openPopup` to see if something like that might be workable? It cannot be positioned, but you can see if the constraints are workable or too limited. + * [benjamin] We can look into that. + * [jonathan] I think there's been 3 main suggestions so far. + * [benjamin] Sounds like we need to do some experimentation to see if Rob's suggestion might be a feasible approach. If it is, we can continue exploration on repositioning the frame. + * [kiara] If it seems viable, we'd be interested in further exploring it. + + +### Triage #0 + +Max 3 minutes per topic. + + +#### [Issue 898](https://github.com/w3c/webextensions/issues/898): Add a way to synthesize user gesture on a page as extension + + * [devlin] At a very high level, supportive of a way to synthesize a user gesture. + * [] What would `event.isTrusted` be? + * [devlin] I would expect it to be set to `true`. + * [kiara] Would this enable extensions to call `permissions.request()` without user gesture? + * [devlin] This proposal is about synthesizing in a web page, not necessarily in extensions. + * [rob] But content scripts can curry the event in Chrome. + * [kiara] (async): we discussed this at TPAC and most browser vendors were opposed to this proposal but were open to a modified version. We should re-discuss this issue. + + +#### [Issue 27](https://github.com/w3c/webextensions/issues/27): tabs.duplicate() must implement a way to duplicate at a given index and with a given active state + + * [oliver] Sounds reasonable. + * [kiara] Already supported in Safari. + * [rob] Firefox already supports this. I'll update the labels. + + +#### [Issue 273](https://github.com/w3c/webextensions/issues/273): Inconsistency: path handling across APIs and browsers + + * [carlos] Would be nice to resolve this inconsistency. + * [rob] In Firefox we resolve relative to the document's URL. For manifest.json we resolve relative to the root. From the API design POV doing it consistently relative to the top level makes sense, but doing so may potentially result in backwards compatibility issues. + * [oliver] In Chrome, `action.setIcon({})` throws, in Firefox it resets to the manifest's default. Are we supportive of aligning with Firefox, Devlin? + * [devlin] Let's open a separate topic for that. + + +#### [Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG? + + * [rob] [Note from the 2024 TPAC meeting](https://github.com/w3c/webextensions/blob/829852ef49cd8b2e1542e08381ec1ca94e7ef8b4/_minutes/2024-09-24-wecg-tpac.md?plain=1#L445-L446) was “handle the proper procedure to update pointers and close the group”. + * [simeon] That seems to have been handled, we can close this issue now. + + +#### [Issue 128](https://github.com/w3c/webextensions/issues/128): Proposal: agree on a unified `sidebar` API for mv3 + + * [devlin] We have discussed this topic multiple times; we are aligned on wanting to align, just need to figure out concrete proposals. + * [rob] And then file implementation bugs. + + +#### [Issue 139](https://github.com/w3c/webextensions/issues/139): Do not outlaw dynamic code + + * [devlin] Comfortable with closing as wontfix? + * [rob] We have since then designed and implemented the userScripts API ([Issue 279](https://github.com/w3c/webextensions/issues/279): User scripts in Manifest V3). + * [jonathan] Their use case may be covered by [Issue 284](https://github.com/w3c/webextensions/issues/284): Main world Content Script shared params + + +#### [Issue 616](https://github.com/w3c/webextensions/issues/616): Content script injection inconsistencies in the sidePanel + + * [carlos] Should align with extension popups. + * [oliver] Yes, should ideally be consistent across extension UI surfaces. + * [devlin] Content scripts into an extension's own iframe sounds reasonable, less clear about iframes from other extensions. + * **Action Item**: Figure out current behavior and then resume discussion. + + +#### [Issue 815](https://github.com/w3c/webextensions/issues/815): Inconsistency: Retrieving closed shadow roots + + * [oliver] I did not put “implemented” on it because it was not clear whether the issue was requesting a property on `Element` or asking about a method on `chrome.dom`. + * [rob] Safari implemented both. On Firefox's behalf I am supportive of also adding it to `browser.dom`, we have had discussions before about functionality that we would add to `browser.dom`. + + +#### [Issue 112](https://github.com/w3c/webextensions/issues/112): Add an API to trigger extension update + + * [devlin] Rob left a comment asking Timothy, Kiara, do you know the answer? + * [kiara] Safari would not implement this, an extension cannot trigger an app update check. + * [rob] On Firefox side we have a patch from a contributor to implement `runtime.requestUpdateCheck`, FYI. + + +#### [Issue 148](https://github.com/w3c/webextensions/issues/148): Proposal: allow webRequest with `background.persistent: false` / SW + + * [devlin] webRequest works in service workers in Chrome. + * [tomislav] Firefox already supports this in event pages, right? + * [rob] Yes. + * [carlos] Safari does not support webRequest listeners in event pages. + + +#### [Issue 755](https://github.com/w3c/webextensions/issues/755): Proposal: `about:` matching + + * [rob] I wouldn't be opposed to `about:*` or even more specific documents. + * [devlin] I think that extensions should specify the origin instead of `about:blank`. + * [oliver] How about `match_origin_as_fallback` behavior? + * [devlin] Sounds good. + * [rob] Sounds reasonable to me as well. + * Consensus: supportive, proposals welcome. diff --git a/_minutes/2026-04-08-london-f2f.md b/_minutes/2026-04-08-london-f2f.md new file mode 100644 index 00000000..eb211c98 --- /dev/null +++ b/_minutes/2026-04-08-london-f2f.md @@ -0,0 +1,621 @@ +# 2026 WECG London F2F, Public Notes, Apr 8 + +Wednesday, the second day of the three-day face-to-face meeting in London (announcement: [#951](https://github.com/w3c/webextensions/issues/951)). Agenda: https://github.com/w3c/webextensions/wiki/2026-London-F2F-Coordination + + +## Agenda + + * [Cross-world extension messaging](#cross-world-extension-messaging) + * [Synchronous properties for content scripts](#synchronous-properties-for-content-scripts) + * [ML/AI](#mlai) + * [Embedding websites in extension pages](#embedding-websites-in-extension-pages) + * [Synchronous properties for content scripts (continued)](#synchronous-properties-for-content-scripts-continued) + * [Triage #1](#triage-1) + * [Issue 557: Proposal: Extension Loading Priority](#issue-557-proposal-extension-loading-priority) + * [Issue 12: request: allow to retrieve a frameID from an <iframe> element](#issue-12-request-allow-to-retrieve-a-frameid-from-an-iframe-element) + * [PR 934: Add runtime.getDocumentId() proposal](#pr-934-add-runtimegetdocumentid-proposal) + * [Issue 862: Proposal: Add sound to contentSettings.](#issue-862-proposal-add-sound-to-contentsettings) + * [Issue 539: Proposal: RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection](#issue-539-proposal-registeredcontentscripttabids-and-registeredcontentscriptexcludetabids-properties-to-filter-injection) + * [Issue 673: Use match\_origin\_as\_fallback behavior by default in scripting.executeScript](#issue-673-use-match_origin_as_fallback-behavior-by-default-in-scriptingexecutescript) + * [Issue 878: Proposal: runtime.getVersion() method](#issue-878-proposal-runtimegetversion-method) + * [Issue 319: Increase the maximum number of dynamic rules to 30,000](#issue-319-increase-the-maximum-number-of-dynamic-rules-to-30000) + * [PR 676: Proposal: Public Suffix API](#pr-676-proposal-public-suffix-api) + * [Issue 172: Proposal: runtime.isFirstInstalled](#issue-172-proposal-runtimeisfirstinstalled) + * [Issue 785: Proposal: create \_generated\_service\_worker.js based on background.scripts](#issue-785-proposal-create-_generated_service_workerjs-based-on-backgroundscripts) + * [Issue 189: Inconsistency: It must be available for iOS](#issue-189-inconsistency-it-must-be-available-for-ios) + * [Issue 399: setUninstallURL length update](#issue-399-setuninstallurl-length-update) + * [Issue 8: executeScript API may inject scripts in an unexpected target at runtime](#issue-8-executescript-api-may-inject-scripts-in-an-unexpected-target-at-runtime) + * [Cross-browser extension mapping](#cross-browser-extension-mapping) + + +## Attendees + + * Devlin Cronin (Google Chrome) + * Oliver Dunk (Google Chrome) + * Patrick Kettner (Google Chrome) + * Rob Wu (Mozilla) + * Tomislav Jovanovic (Mozilla) + * Kiara Rose (Apple) + * Timothy Hatcher (Apple) (remote) + * Carlos Jeurissen (Jeurissen Apps) + * Ben Greenberg (Aglide) + * Jonathan Kingston (DuckDuckGo) + * Dave Vandyke (DuckDuckGo) + * Simeon Vincent (Independent) + * Benjamin Bruneau (1Password) + * Brandon Lucier (1Password) + * Dean Murphy (eyeo) + * Mukul Pirohit (Microsoft) + * Nitisha Rathi (Microsoft) + * Jordan Spivack (Capital One) + * Casey Garland (Capital One) + * Thomas Greiner (eyeo) + * Jan Biniok (Tampermonkey) (remote) + * Maxim Topciu (AdGuard) (remote) + * Andre Bandarra (Google Chrome) (ML/AI topic only) + * David Johnson (Apple) (remote, cross-browser mapping topic only) + + +## Notes + + +### Cross-world extension messaging + + * (9:30) + * Cross-world messaging + * [PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() + * [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() + * [simeon] PRs created by Devlin. Status of these proposals? + * [devlin] Overview: These two are different APIs in the `dom` namespace to allow content scripts to interact with the main world. Currently have to inject a `