-
Notifications
You must be signed in to change notification settings - Fork 72
Publish minutes of 2025-05-22 meeting #834
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,128 @@ | ||
| # WECG Meetings 2025, Public Notes, May 22 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=682e6900,384 | ||
| Call-in details: [WebExtensions CG, 22nd May 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250522T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #824](https://github.com/w3c/webextensions/issues/824), [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) | ||
| * It's tech keynote season! | ||
| * **Triage** (20 minutes) | ||
| * [Issue 825](https://github.com/w3c/webextensions/issues/825): Inconsistency: Default content security policy ([@erosman](https://github.com/erosman)) | ||
| * [Issue 830](https://github.com/w3c/webextensions/issues/830): Proposal: Allow specifying different popup HTML for auto-resizing vs. fixed-size windows ([@muzuiget](https://github.com/muzuiget)) | ||
| * [Pull 826](https://github.com/w3c/webextensions/pull/826): Proposal: Allow extensions to track their own disable/uninstall events without "management" permission ([@jaissam10](https://github.com/jaissam10)) | ||
| * [Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 | ||
| * [Issue 831](https://github.com/w3c/webextensions/issues/831): Canonical header names | ||
| * [Issue 833](https://github.com/w3c/webextensions/issues/833): Side Panel API: query position: left/right, close(), and focus(): tab to and from side panel | ||
| * **Timely issues** (0 minutes) | ||
| * None | ||
| * **Check-in on existing issues** (5 minutes) | ||
| * [Pull 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification ([@oliverdunk](https://github.com/oliverdunk)) | ||
| * **Discuss nominated topics** | ||
| * [Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 | ||
| * [Issue 831](https://github.com/w3c/webextensions/issues/831): Canonical header names | ||
| * [Issue 833](https://github.com/w3c/webextensions/issues/833): Side Panel API: query position: left/right, close(), and focus(): tab to and from side panel | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. David Johnson (Apple) | ||
| 3. Timothy Hatcher (Apple) | ||
| 4. Simeon Vincent (Mozilla) | ||
| 5. Maxim Topciu (AdGuard) | ||
| 6. Mukul Purohit (Microsoft) | ||
| 7. Solomon Kinard (Chromium) | ||
| 8. Tomislav Jovanovic (Mozilla) | ||
| 9. Carlos Jeurissen (Jeurissen Apps) | ||
| 10. Oleksii Levzhynskyi (Grammarly) | ||
| 11. Oliver Dunk (Google) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Note on keynotes | ||
|
|
||
| * [simeon] Many tech keynotes! Build, I/O, AI companies, WWDC is coming up in 2 weeks! | ||
| * [oliver] Google I/O talks: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/dRcCXIe4RlQ/m/R056FM6bAAAJ | ||
| * [mukul] Microsoft Build Announcements | ||
| [Simplified access to AI in Microsoft Edge: Introducing the Prompt and Writing Assistance APIs - Microsoft Edge Blog](https://blogs.windows.com/msedgedev/2025/05/19/introducing-the-prompt-and-writing-assistance-apis/) | ||
|
|
||
| [Issue 825](https://github.com/w3c/webextensions/issues/825): Inconsistency: Default content security policy | ||
|
|
||
| * [rob] I have context. A while ago I suggested defaulting to HTTPS in extensions. Good way to help secure use data by transmitting it over secure connections. We've added upgrade requests by default to CSP. This could break some extensions if the backend doesn't support CSP. This creates an inconsistency where we're the only ones that enable HTTPS by default. Developers can easily opt out by specifying a custom CSP without `upgrade-insecure-requests`. | ||
| * [oliver] Not familiar with this directive. Is it limited to script src? | ||
| * [rob] No, it is a separate directive, not a value for script-src. | ||
| * [rob] Any appetite from other browsers to introducing upgrades to HTTPS by default? | ||
| * [timothy] Open to it. Did this create any breakages? | ||
| * [rob] This is the first report I've heard of concerns with enabling this. | ||
| * [tomislav] We added this in MV3 only, so did not break backwards compatibility in MV2. | ||
| * [rob] Add-ons Policies require transmitting data over secure channels, so this change is consistent with that. | ||
| * [oliver] Could be a breaking change, so I have to discuss it with Chrome's engineering team. | ||
| * [rob] So maybe in the next manifest revision? | ||
| * [oliver] Would want to check with the team, but that's my impression. | ||
| * [timothy] Probably the best course of action to play it safe. | ||
| * [oliver] This is likely not a trivial change; some enterprises may not support http for everything. Does this mean Firefox doesn't allow HTTP on localhost? | ||
| * [tomislav] Developers can opt out. Sets a default level of security, but developers can change it. | ||
| * [oliver] That reduces concerns about breaking changes. | ||
| * [timothy] Also can be super subtle – hard to detect and debug if you don't know about this class of issue. | ||
|
|
||
| [Issue 830](https://github.com/w3c/webextensions/issues/830): Proposal: Allow specifying different popup HTML for auto-resizing vs. fixed-size windows | ||
|
|
||
| * [timothy] We all size based on intrinsic size. Not sure about use case. We show the popup on phones as well, which could be a mini or a plus size phone. | ||
| * [carlos] This is not as straightforward as it seems initially. Currently there is no good contract between the wishes of the extension developer and the browser. Existing issues being extensions sometimes open as tiny popup and need specific resizing of html/body tags to trigger proper sizing. One may want to delay loading content due to this issue. Resulting in a less optimal experience. | ||
| * [simeon] Is this something that can be addressed by best practices? E.g. specifying a specific fixed size. | ||
| * [timothy] the sizing may differ depending on the state of the device. iPads might give an auto sizing in landscape, while giving a fixed size in portrait. | ||
| * [carlos] In that case seems a CSS solution would be preferred | ||
| * [rob] Would we consider allowing extensions to specify preferred dimensions upfront, so that the browser does not have to do too many guesses? | ||
| * [simeon] Would it be in manifest or CSS? | ||
| * [timothy] In the manifest would be preferable, so the information is available before loading. | ||
| * [carlos] What do we do with the issue? Keep open? Merge with existing topics? | ||
| * [rob] I'd close this. The specific proposal of allowing different pages to be declared dependent on size is not something I'd like to pursue. | ||
| * [timothy] Agreeing with Rob here. | ||
|
|
||
| [Pull 826](https://github.com/w3c/webextensions/pull/826): Proposal: Allow extensions to track their own disable/uninstall events without "management" permission | ||
|
|
||
| * [simeon] I think that the case is already served by `runtime.setUninstallURL()`. Hesitant with observing onDisabled/onUninstalled, because extension would be unloaded and not be able to receive them. | ||
| * [timothy] We shut down as quick as possible. | ||
| * [lesha] For extensions, there is value in uninstall/disable metrics, as it could be a sign of issues in an extension, that may require a rollback or update. | ||
| * [simeon] onInstalled can be used to detect initial installation (except for installing through sync, which we've discussed before). runtime.setUninstallURL can be used to detect removal. | ||
| * [rob] I'm inclined to close this request. No way we can provide this. Detecting uninstallation is an abuse vector. The runtime.onInvalidated event in content scripts is the closest work-around that we can consider supporting. | ||
|
|
||
| [Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 | ||
|
|
||
| * [carlos] Can extension authors assume that tabId 0 is invalid/missing, or is it a valid ID? Seen in Safari. | ||
| * [timothy] Sounds like a bug in Safari. Missing data and defaulting to 0. | ||
| * [simeon] I have a vague recollection of tabId 0 being the extension's background context | ||
| * [rob] That's -1, which represents no tab ID. tabId is at least 1 in practice, in Firefox, but it is not documented. | ||
| * [simeon] Was -2 used for pretenders? | ||
| * [rob] That is windows.WINDOW_ID_CURRENT. | ||
| * [timothy] I can align on avoiding 0 if we all want to do that. In this case it is a bug that was resolved. I am supportive of starting at 1. | ||
| * [rob] I am also willing to start at 1, that is already what we do in Firefox. | ||
| * [oliver] I have to check for Chrome. | ||
|
|
||
| [Issue 831](https://github.com/w3c/webextensions/issues/831): Canonical header names | ||
|
|
||
| * [carlos] the casing of header names is inconsistent between browsers and extension APIs. For example, the dnr header append in Chrome only accepts lower case. Ideally browsers are forgiving when getting passed a header name in terms of casing while being consistent when returning header names in APIs like the webRequest API. | ||
| * [rob] Firefox's extension API does not change the casing of headers. If you see lower case headers, it could be due to header compression (HPACK) in http2 for example; in that case the raw header name is not even present in the request itself, and the browser fills in the (lower case) header names. Could this be what you are witnessing? | ||
| * [carlos] Maybe. | ||
| * [simeon] Should we normalize headers, e.g. to all lower case? | ||
| * [rob] Although headers should be case insensitive, some clients may treat them case sensitively. Exposing whatever was received from the server would make more sense, then extensions can (and will) choose to normalize as needed. | ||
|
|
||
| [Issue 833](https://github.com/w3c/webextensions/issues/833): Side Panel API: query position: left/right, close(), and focus(): tab to and from side panel | ||
|
|
||
| * [solomon] Proposing sidePanel API enhancements: Query position (left/right), close method, change focus. | ||
| * [simeon] Focus was discussed before, at https://github.com/w3c/webextensions/issues/693. | ||
| * [oliver] FYI: Part of Google Summer of Code. | ||
| * [oliver] CL: https://chromium-review.googlesource.com/c/chromium/src/+/6576001 | ||
|
|
||
| The next meeting will be on [Thursday, June 5th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6840de00,384). | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.