|
| 1 | +# WECG Meetings 2025, Public Notes, May 22 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=682e6900,384 |
| 7 | +Call-in details: [WebExtensions CG, 22nd May 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250522T080000/) |
| 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 #824](https://github.com/w3c/webextensions/issues/824), [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 | + * It's tech keynote season! |
| 19 | + * **Triage** (20 minutes) |
| 20 | + * [Issue 825](https://github.com/w3c/webextensions/issues/825): Inconsistency: Default content security policy ([@erosman](https://github.com/erosman)) |
| 21 | + * [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)) |
| 22 | + * [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)) |
| 23 | + * [Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 |
| 24 | + * [Issue 831](https://github.com/w3c/webextensions/issues/831): Canonical header names |
| 25 | + * [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 |
| 26 | + * **Timely issues** (0 minutes) |
| 27 | + * None |
| 28 | + * **Check-in on existing issues** (5 minutes) |
| 29 | + * [Pull 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification ([@oliverdunk](https://github.com/oliverdunk)) |
| 30 | + * **Discuss nominated topics** |
| 31 | + * [Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 |
| 32 | + * [Issue 831](https://github.com/w3c/webextensions/issues/831): Canonical header names |
| 33 | + * [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 |
| 34 | + |
| 35 | + |
| 36 | +## Attendees (sign yourself in) |
| 37 | + |
| 38 | + 1. Rob Wu (Mozilla) |
| 39 | + 2. David Johnson (Apple) |
| 40 | + 3. Timothy Hatcher (Apple) |
| 41 | + 4. Simeon Vincent (Mozilla) |
| 42 | + 5. Maxim Topciu (AdGuard) |
| 43 | + 6. Mukul Purohit (Microsoft) |
| 44 | + 7. Solomon Kinard (Chromium) |
| 45 | + 8. Tomislav Jovanovic (Mozilla) |
| 46 | + 9. Carlos Jeurissen (Jeurissen Apps) |
| 47 | + 10. Oleksii Levzhynskyi (Grammarly) |
| 48 | + 11. Oliver Dunk (Google) |
| 49 | + |
| 50 | + |
| 51 | +## Meeting notes |
| 52 | + |
| 53 | +Note on keynotes |
| 54 | + |
| 55 | + * [simeon] Many tech keynotes! Build, I/O, AI companies, WWDC is coming up in 2 weeks! |
| 56 | + * [oliver] Google I/O talks: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/dRcCXIe4RlQ/m/R056FM6bAAAJ |
| 57 | + * [mukul] Microsoft Build Announcements |
| 58 | + [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/) |
| 59 | + |
| 60 | +[Issue 825](https://github.com/w3c/webextensions/issues/825): Inconsistency: Default content security policy |
| 61 | + |
| 62 | + * [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`. |
| 63 | + * [oliver] Not familiar with this directive. Is it limited to script src? |
| 64 | + * [rob] No, it is a separate directive, not a value for script-src. |
| 65 | + * [rob] Any appetite from other browsers to introducing upgrades to HTTPS by default? |
| 66 | + * [timothy] Open to it. Did this create any breakages? |
| 67 | + * [rob] This is the first report I've heard of concerns with enabling this. |
| 68 | + * [tomislav] We added this in MV3 only, so did not break backwards compatibility in MV2. |
| 69 | + * [rob] Add-ons Policies require transmitting data over secure channels, so this change is consistent with that. |
| 70 | + * [oliver] Could be a breaking change, so I have to discuss it with Chrome's engineering team. |
| 71 | + * [rob] So maybe in the next manifest revision? |
| 72 | + * [oliver] Would want to check with the team, but that's my impression. |
| 73 | + * [timothy] Probably the best course of action to play it safe. |
| 74 | + * [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? |
| 75 | + * [tomislav] Developers can opt out. Sets a default level of security, but developers can change it. |
| 76 | + * [oliver] That reduces concerns about breaking changes. |
| 77 | + * [timothy] Also can be super subtle – hard to detect and debug if you don't know about this class of issue. |
| 78 | + |
| 79 | +[Issue 830](https://github.com/w3c/webextensions/issues/830): Proposal: Allow specifying different popup HTML for auto-resizing vs. fixed-size windows |
| 80 | + |
| 81 | + * [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. |
| 82 | + * [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. |
| 83 | + * [simeon] Is this something that can be addressed by best practices? E.g. specifying a specific fixed size. |
| 84 | + * [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. |
| 85 | + * [carlos] In that case seems a CSS solution would be preferred |
| 86 | + * [rob] Would we consider allowing extensions to specify preferred dimensions upfront, so that the browser does not have to do too many guesses? |
| 87 | + * [simeon] Would it be in manifest or CSS? |
| 88 | + * [timothy] In the manifest would be preferable, so the information is available before loading. |
| 89 | + * [carlos] What do we do with the issue? Keep open? Merge with existing topics? |
| 90 | + * [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. |
| 91 | + * [timothy] Agreeing with Rob here. |
| 92 | + |
| 93 | +[Pull 826](https://github.com/w3c/webextensions/pull/826): Proposal: Allow extensions to track their own disable/uninstall events without "management" permission |
| 94 | + |
| 95 | + * [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. |
| 96 | + * [timothy] We shut down as quick as possible. |
| 97 | + * [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. |
| 98 | + * [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. |
| 99 | + * [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. |
| 100 | + |
| 101 | +[Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 |
| 102 | + |
| 103 | + * [carlos] Can extension authors assume that tabId 0 is invalid/missing, or is it a valid ID? Seen in Safari. |
| 104 | + * [timothy] Sounds like a bug in Safari. Missing data and defaulting to 0. |
| 105 | + * [simeon] I have a vague recollection of tabId 0 being the extension's background context |
| 106 | + * [rob] That's -1, which represents no tab ID. tabId is at least 1 in practice, in Firefox, but it is not documented. |
| 107 | + * [simeon] Was -2 used for pretenders? |
| 108 | + * [rob] That is windows.WINDOW_ID_CURRENT. |
| 109 | + * [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. |
| 110 | + * [rob] I am also willing to start at 1, that is already what we do in Firefox. |
| 111 | + * [oliver] I have to check for Chrome. |
| 112 | + |
| 113 | +[Issue 831](https://github.com/w3c/webextensions/issues/831): Canonical header names |
| 114 | + |
| 115 | + * [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. |
| 116 | + * [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? |
| 117 | + * [carlos] Maybe. |
| 118 | + * [simeon] Should we normalize headers, e.g. to all lower case? |
| 119 | + * [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. |
| 120 | + |
| 121 | +[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 |
| 122 | + |
| 123 | + * [solomon] Proposing sidePanel API enhancements: Query position (left/right), close method, change focus. |
| 124 | + * [simeon] Focus was discussed before, at https://github.com/w3c/webextensions/issues/693. |
| 125 | + * [oliver] FYI: Part of Google Summer of Code. |
| 126 | + * [oliver] CL: https://chromium-review.googlesource.com/c/chromium/src/+/6576001 |
| 127 | + |
| 128 | +The next meeting will be on [Thursday, June 5th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6840de00,384). |
0 commit comments