|
| 1 | +# WECG Meetings 2025, Public Notes, Mar 27 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=67e49500,384 |
| 7 | +Call-in details: [WebExtensions CG, 27th March 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250327T080000/) |
| 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 #781](https://github.com/w3c/webextensions/issues/781), [github issues](https://github.com/w3c/webextensions/issues) |
| 12 | + |
| 13 | +The meeting will start at 3 minutes after the hour. |
| 14 | + |
| 15 | +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. |
| 16 | + |
| 17 | + * **Announcements** (2 minutes) |
| 18 | + * **Triage** (15 minutes) |
| 19 | + * [Issue 782](https://github.com/w3c/webextensions/issues/782): Why does DNR modifyHeaders require host permissions? |
| 20 | + * [Issue 784](https://github.com/w3c/webextensions/issues/784): Handling of empty background script definitions |
| 21 | + * [Issue 785](https://github.com/w3c/webextensions/issues/785): Proposal: create \_generated_service_worker.js based on background.scripts |
| 22 | + * [Issue 786](https://github.com/w3c/webextensions/issues/786): Proposal: Allow extension contexts to set forbidden headers in fetch() API |
| 23 | + * [Issue 787](https://github.com/w3c/webextensions/issues/787): extension API availability in extension frames embedded on third party websites |
| 24 | + * [Issue 790](https://github.com/w3c/webextensions/issues/790): Proposal: browser.permissions.isAccessible() |
| 25 | + * [Pull 793](https://github.com/w3c/webextensions/pull/793): Add proposal: Synchronous data at startup |
| 26 | + * [Pull 779](https://github.com/w3c/webextensions/pull/779): Sidepanel lifecycle events proposal |
| 27 | + * [Pull 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification |
| 28 | + * [Pull 792](https://github.com/w3c/webextensions/pull/792): Proposal: runtime.onInvalidated event |
| 29 | + * **Timely issues** (10 minutes) |
| 30 | + * **Check-in on existing issues** (20 minutes) |
| 31 | + |
| 32 | + |
| 33 | +## Attendees (sign yourself in) |
| 34 | + |
| 35 | + 1. Rob Wu (Mozilla) |
| 36 | + 2. Simeon Vincent (Mozilla) |
| 37 | + 3. Oliver Dunk (Google Chrome) |
| 38 | + 4. Devlin Cronin (Google Chrome) |
| 39 | + 5. Simeon Vincent (Mozilla) |
| 40 | + 6. Tomislav Jovanovic (Mozilla) |
| 41 | + 7. Carlos Jeurissen (Jeurissen Apps) |
| 42 | + 8. Mukul Purohit (Microsoft Edge) |
| 43 | + 9. Timothy Hatcher (Apple) |
| 44 | + 10. Maxim Topciu (AdGuard) |
| 45 | + 11. David Tota (AdGuard) |
| 46 | + 12. Kiara Rose (Apple) |
| 47 | + 13. Casey Garland (Capital One) |
| 48 | + 14. Jordan Spivack (Capital One) |
| 49 | + 15. Krzysztof Modras (Ghostery) |
| 50 | + 16. Jan (Tampermonkey) |
| 51 | + 17. Oleksii Levzhynskyi (Grammarly) |
| 52 | + 18. Giorgio Maone (Tor, NoScript) |
| 53 | + 19. Aaron Selya (Google) |
| 54 | + 20. Rishik Ramena (Microsoft Edge) |
| 55 | + 21. David Johnson (Apple) |
| 56 | + 22. Mostafa Aboalkasim (Individual) |
| 57 | + |
| 58 | + |
| 59 | +## Meeting notes |
| 60 | + |
| 61 | +[Issue 782](https://github.com/w3c/webextensions/issues/782): Why does DNR modifyHeaders require host permissions? |
| 62 | + |
| 63 | + * [simeon] The direct answer to the title question is that not all modifications can be made without user consent. |
| 64 | + * [rob] Can we close this, or is there a reason for keeping this open? |
| 65 | + * [timothy] Agreed with closing it. |
| 66 | + |
| 67 | +[Issue 784](https://github.com/w3c/webextensions/issues/784): Handling of empty background script definitions |
| 68 | + |
| 69 | + * [carlos] What should the behavior be when background.scripts is empty, or background is an empty object. |
| 70 | + * [oliver] Don't feel too strongly about a soft warning. |
| 71 | + * [rob] Does Chrome allow background with empty object? |
| 72 | + * [timothy] I think we will complain with a warning but not an error. |
| 73 | + * [carlos] I can submit a patch to turn the error into a warning. |
| 74 | + * [rob] I'd approve that. |
| 75 | + * [timothy] And I'll file an internal issue for what you mentioned in the issue. |
| 76 | + |
| 77 | +[Issue 785](https://github.com/w3c/webextensions/issues/785): Proposal: create \_generated_service_worker.js based on background.scripts |
| 78 | + |
| 79 | + * [carlos] This was originally proposed in the issue on preferred_environment. Wondering whether this is something browsers are in favor of. |
| 80 | + * [oliver] I added “opposed” because when we discussed this in the past, there were concerns about confusion. |
| 81 | + * [devlin] Sufficient potential for confusion to not want this. |
| 82 | + * [carlos] Safari successfully implemented this. |
| 83 | + * [devlin] I can see the value when we have different background definitions. |
| 84 | + * [oliver] Another use case is when an extension has a library dependency. |
| 85 | + * [simeon] I hear the argument about not being wild about magic behavior. When I started, while it was surprising for a page to magically exist, it was also more ergonomic. |
| 86 | + * [devlin] See the value of doing this to support the same extension across multiple browsers. |
| 87 | + * [simeon] Thoughts from Firefox? |
| 88 | + * [rob] We support `type=”module”` for event pages and we don't support service workers. |
| 89 | + * [krzysztof] It's a one-time issue that developers would have encountered during migrations. But the request is to improve this so individuals don't have to discover and implement their own workarounds. |
| 90 | + * [rob] I'm neutral. |
| 91 | + * [devlin] Also neutral. |
| 92 | + * [rob] Does that mean that if someone were to submit a patch, that you would be willing to accept it? |
| 93 | + * [devlin] … sure. |
| 94 | + * [oliver] Timothy, can you clarify Safari behavior? |
| 95 | + * [timothy] If it's just scripts, it's a background page. If you specify `”preferred_envrionment”: “service_worker”`, it is a service worker based on `service_worker` (or auto-generated from `scripts` if `service_worker` is absent). |
| 96 | + |
| 97 | +[Issue 786](https://github.com/w3c/webextensions/issues/786): Proposal: Allow extension contexts to set forbidden headers in fetch() API |
| 98 | + |
| 99 | + * [oliver] Other spec authors are seeking official support before proceeding. |
| 100 | + * [devlin] Intent is to only expose this in a trusted execution environment. |
| 101 | + * [timothy] Makes sense. |
| 102 | + * [rob] When I asked about this internally, the only question was about availability in content scripts, and to that I replied that we only want to support this in a privileged extension context, NOT content scripts. |
| 103 | + * [oleksii] Why do we want to update a web spec? |
| 104 | + * [devlin] For context, there have been a number of times where developers have said “it would be nice if I could do X” where X is 98% like an extension web API, but with a specific, slightly different behavior for extensions. We don't want to reinvent the wheel. |
| 105 | + * [jan] What is the timeframe for having this feature? |
| 106 | + * [devlin] Right now we are at whether we can even do this, whether the open web platform is willing to accept this. |
| 107 | + * [oliver] Feedback I have heard from extension developers is whether Origin can also be spoofed, since some extensions rely on that. |
| 108 | + * [rob] In Firefox we require extensions to have the permission for domain specified in the Host request header; could require something similar for extension origins. |
| 109 | + |
| 110 | +[Issue 787](https://github.com/w3c/webextensions/issues/787): extension API availability in extension frames embedded on third party websites |
| 111 | + |
| 112 | + * [carlos] Behavior of browser is inconsistent when it comes to extension API availability in extension frames. In Chrome it is available. |
| 113 | + * [rob] Historically Chrome had Firefox's behavior, until they implemented Site Isolation, where these frames are hosted in the extension process. |
| 114 | + * [tomislav] May break existing extensions. I think that Safari has one process per tab, so they could not do it securely either. |
| 115 | + * [timothy] Yes, working on multiple processes though. |
| 116 | + * [carlos] Ok, so extension pages should communicate with the background pages. |
| 117 | + |
| 118 | +[Issue 790](https://github.com/w3c/webextensions/issues/790): Proposal: browser.permissions.isAccessible() |
| 119 | + |
| 120 | + * [carlos] Extension can have permissions for specific websites, but they cannot act on the Chrome Web Store because it is a privileged page. My proposal is to have a method that returns whether the extension can access the origin. |
| 121 | + * [tomislav] I have had this idea as well; someone asked whether it can be available synchronously, and the answer is no. Useful, but can potentially leak user information. |
| 122 | + * [devlin] I don't think that it leaks info, an extension can already leak information. |
| 123 | + * [rob] Different levels of access: sending network requests, reading the URL, being able to inject a script. Extension can already check this. What's the benefit to having an API for this? |
| 124 | + * [carlos] Avoid side effects. |
| 125 | + * [devlin] I'm hesitant about advising devs try to do things and |
| 126 | + * [rob] On the name, should not be “isAccessible” due to potential confusion with the “accessibility” concept. |
| 127 | + * [carlos] Sounds like it should be async |
| 128 | + * [oleksii] If it is not solely dependent on permissions, should it belong somewhere else than the “permissions” namespace. |
| 129 | + * [devlin] The point of this is it's not just checking the extension permissions |
| 130 | + * [timothy] Should this be on the permissions namespace? |
| 131 | + * [devlin] I'd put it there. It ties it into the concept of permissions. |
| 132 | + * [oliver] Would it be useful to support `tabId`, `frameId`, `documentId`. |
| 133 | + * [timothy] We should handle `tabId`, since `activeTab` can affect the answer per tab. |
| 134 | + * [devlin] Naming, would prefer to avoid “origin” in the name. Want to be able to support other use cases. Would want to return an object rather than a boolean. |
| 135 | + |
| 136 | +[Pull 793](https://github.com/w3c/webextensions/pull/793): Add proposal: Synchronous data at startup |
| 137 | + |
| 138 | + * [rob] There have been several use cases where extensions want to initialize state and synchronously access it later. This proposal addresses content scripts (the initial use case) |
| 139 | + * [simeon] How is data handled across extension updates? |
| 140 | + * [rob] Doesn't persist by default, but there's a setting to control this |
| 141 | + * [giorgio] [Proposal has two major limitations](https://github.com/w3c/webextensions/pull/793#issuecomment-2758503261): can't tell if configuration for a tab is applicable to a script and configuration per site isn't covered. |
| 142 | + * [rob] Per-site configurations can be supported by the extension including the site in the key name. By design, the values are lazily deserialized. |
| 143 | + * [rob] I'll respond asynchronously on the issue because of time constraints. |
| 144 | + * [rob] Anyone interested - please state how much quota you'd like to have. |
| 145 | + * [oliver] Since there aren't ancestor origins in Firefox, may be difficult to target settings for a site. |
| 146 | + * [rob] Willing to consider exposing the top's origin through an extension API, since the privacy concerns around location.ancestorOrigins may not be a concern in the extension scenario. |
| 147 | + |
| 148 | +[Pull 779](https://github.com/w3c/webextensions/pull/779): Sidepanel lifecycle events proposal |
| 149 | + |
| 150 | + * [rishik] Created a proposal based on previous discussion. Currently have onCreated and onClosed events. |
| 151 | + * [oliver] For clarity, the problem with onClosed vs onHidden is that (at least previously, I think still) we sometimes keep extension pages used in a side panel in memory even when it is no longer showing to the user. In that case, do we fire onClosed or not? Similarly, do we fire onOpen if the user opens a side panel not associated with this extension? |
| 152 | + * [devlin] I think we can have both onClosed and onHidden. |
| 153 | + |
| 154 | +[Pull 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification |
| 155 | + |
| 156 | + * [] (skipped, out of time) |
| 157 | + |
| 158 | +[Pull 792](https://github.com/w3c/webextensions/pull/792): Proposal: runtime.onInvalidated event |
| 159 | + |
| 160 | + * [] (skipped, out of time; already discussed during the face-to-face) |
| 161 | + |
| 162 | +The next meeting will be on [Thursday, April 10th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=67f70a00,384). Europe Daylight saving time ends on March 30th, so for those in Europe the meeting has returned to 5 PM instead of 4 PM. |
0 commit comments