|
| 1 | +# WECG Meetings 2025, Public Notes, Jun 5 |
| 2 | + |
| 3 | +* Chair: Kiara Rose |
| 4 | +* Scribes: Simeon Vincent |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=6840de00,384 |
| 7 | +Call-in details: [WebExtensions CG, 5th June 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250605T080000/) |
| 8 | +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) |
| 9 | + |
| 10 | +## Agenda: [discussion in #835](https://github.com/w3c/webextensions/issues/835), [github issues](https://github.com/w3c/webextensions/issues) |
| 11 | + |
| 12 | +The meeting will start at 3 minutes after the hour. |
| 13 | + |
| 14 | +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. |
| 15 | + |
| 16 | + * **Announcements** (2 minutes) |
| 17 | + * **Triage** (15 minutes) |
| 18 | + * [Issue 839](https://github.com/w3c/webextensions/issues/839): Proposal: Consider allowing CSS injection irrespective of CSP |
| 19 | + * [Issue 836](https://github.com/w3c/webextensions/issues/836): Allow extensions to track their own disable/uninstall events |
| 20 | + * **Timely issues** (10 minutes) |
| 21 | + * [Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API |
| 22 | + * [Issue 837](https://github.com/w3c/webextensions/pull/837): Proposal: close() Method for the sidePanel API |
| 23 | + * [Issue 838](https://github.com/w3c/webextensions/pull/838): Proposal: API to Query Side Panel Position |
| 24 | + * **Check-in on existing issues** (20 minutes) |
| 25 | + * [Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 |
| 26 | + * [tom] WPT check-in, any next step on the RFC https://github.com/web-platform-tests/rfcs/pull/219 |
| 27 | + * [timothy] TPAC update |
| 28 | + * [simeon] Working Group update |
| 29 | + * [PR 792](https://github.com/w3c/webextensions/pull/792) [carlos] Rob approved the onInvalidated (which was the only pending review), can we merge? |
| 30 | + |
| 31 | +## Attendees (sign yourself in) |
| 32 | + |
| 33 | + 1. Kiara Rose (Apple) |
| 34 | + 2. Tomislav Jovanovic (Mozilla) |
| 35 | + 3. Timothy Hatcher (Apple) |
| 36 | + 4. David Johnson (Apple) |
| 37 | + 5. Oliver Dunk (Google) |
| 38 | + 6. David Tota (AdGuard) |
| 39 | + 7. Simeon Vincent (Mozilla) |
| 40 | + 8. Carlos Jeurissen (Jeurissen Apps) |
| 41 | + 9. Martin Verde (Google) |
| 42 | + 10. Harsh (Google, Summer of Code) |
| 43 | + |
| 44 | +## Meeting notes |
| 45 | + |
| 46 | +Announcements |
| 47 | + |
| 48 | + * [kiara] Next meeting is on Jun 19, 2025, which is Juneteenth in the US. Apple folks have it off. |
| 49 | + * [oliver] I will be available either way. |
| 50 | + * [simeon] Disadvantageous to not have Apple present. |
| 51 | + * [tomislav] Happy to skip to support this holiday. |
| 52 | + * [kiara] Okay, we'll skip the next meeting. |
| 53 | + |
| 54 | +[Issue 839](https://github.com/w3c/webextensions/issues/839): Proposal: Consider allowing CSS injection irrespective of CSP |
| 55 | + |
| 56 | + * [kiara] Not sure if this is a case we'd want to support, but open to discussion. |
| 57 | + * [timothy] There is no safe way to make this kind of allowance. Previously discussed related to JS. CSP usually allows images from anywhere. Tricky space. |
| 58 | + * [simeon] Not sure I follow the request. Is this content injected from the extension or remote resources? |
| 59 | + * [oliver] I took this to mean a content script that appends a CSS file. |
| 60 | + * [timothy] It's about remote CSS and fonts. |
| 61 | + * [oliver] I think both as it also mentions the scripting API and content_scripts manifest key. |
| 62 | + * [timothy] Yes, we likely need more detail here about the specific request. |
| 63 | + * [simeon] If this is about extension resources, I'm interested in better understanding the problem. My position is we should have better tools to allow CSP handling of extension resources. But if it's for remote resources I share Timothy's concerns. |
| 64 | + |
| 65 | +[Issue 836](https://github.com/w3c/webextensions/issues/836): Allow extensions to track their own disable/uninstall events |
| 66 | + |
| 67 | + * [simeon] This issue was created to move the conversation from a specific pull request to a more generic discussion of the issue. I need to migrate a couple of comments from the PR to populate this discussion. At the moment my impression is that uninstall URL addresses the uninstall use case. It’s not clear to me what the use case is for tracking the disabled event. My current view is that unless this is in direct support of functionality that directly benefits the user it shouldn’t be added to the platform. Restated, I’m currently against exposing an event purely for data collection purposes. That said, not closing the door. I want to understand the use case. Seems like the beacon API may be an appropriate way to ensure that metrics are logged all the way up to disable/uninstall. |
| 68 | + * [tomislav] Beacon is async from the execution context. Controllable by the user–they can disable beacon support. If anything I’m supportive of that. Hesitant about directly exposing events for data collection. |
| 69 | + * [david] Seems rife for annoyance. |
| 70 | + * [simeon] Not sure about policy-enforced extensions, does it trigger the uninstall URL? |
| 71 | + * [kiara] We don't support `uninstallSelf()`, but would expect that if removed from a force install list it wouldn't show. |
| 72 | + * [oliver] I believe we only show the uninstall URL if it was user initiated. |
| 73 | + * [simeon] Sounds like we're aligned on general intent, but might need confirmation of current implementation behavior. |
| 74 | + |
| 75 | +[Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API |
| 76 | + |
| 77 | + * [martin] Brought this proposal a few months ago. Consensus as I recall was that we should get feedback from developers around potential impact. Identified that there are some rules that are in use by major popular extensions that might be affected by this change. Got feedback from some developers including AdGuard (present today), indicating that this may be a useful change to make to reduce the number of rules required. There's a recent suggestion to the PR to add a flag to perform rule normalization. Current plan is to enable it by default and allow opt-out. |
| 78 | + * [oliver] We discussed a little about opt in vs. opt out. Opt in initially sounds appealing, but enabling by default seems like the more useful case in general. Opt out gives us an escape hatch for cases where this behavior presents a problem. |
| 79 | + * [timothy] Sounds good. Only nitpick is the naming of the key. Suggest dropping “do”. Sounds awkward. |
| 80 | + * [martin] Discussed this a little. Current fields start with a verb, which is why we have “do”. |
| 81 | + * [timothy] Suggest capitalizing URL in the name |
| 82 | + * [oliver] Not compatible with isUrlCaseSensitive |
| 83 | + * [carlos] Something to consider when deciding on opt-in vs opt-out is the fact having an unknown property in DNR would throw on older browsers not recognising the new property. |
| 84 | + * [timothy] Godo point. Had the same issue with isUrlCaseSensitive, but would break older browsers for these specific rules. Do we have a sense of how many rules would break? |
| 85 | + * [oliver] We had 10,000, was that across all, Martin? |
| 86 | + * [martin] Yes, 10,000 in total. |
| 87 | + * [oliver] Doesn't seem like many of these rules are broadly applicable. For example, not blocking a specific Google Docs file. |
| 88 | + * [david] What about adding a single opt in at the top of the manifest? Too much burden? |
| 89 | + * [oliver] Burden might not be the right word, but concerned about cases where devs forget to enable and get unexpected behavior. |
| 90 | + * [timothy] Know we talked about this before, but what happens with unknown keys. |
| 91 | + * [simeon] As I recall it applies as much as it can. |
| 92 | + * [tomislav] That sounds right, but not 100% sure as that's Rob's domain. |
| 93 | + * [oliver] Sounds like we're aligned that adding this normalization makes sense. Field name needs some bikeshedding. Need to align on behavior regarding older browser versions. |
| 94 | + * [david] We're particularly concerned about API and binary compatibility for extensions that don't immediately update. |
| 95 | + * [oliver] Is this something other browsers have an appetite to implement in the future? |
| 96 | + * [timothy] Makes sense, I'd be supportive. |
| 97 | + * [oliver] I think we have a good path. Any other questions, Martin? |
| 98 | + * [martin] Don't think so. Need to decide opt in vs. opt out. |
| 99 | + * [oliver] Expect we'll have to come back to the group at least once. May need to change the name of the field, but that's easy to do. |
| 100 | + * [martin] We'll double check the behavior in Chrome for backwards compatibility. |
| 101 | + * [tomislav] Please check Firefox and Safari as well. |
| 102 | + |
| 103 | +[Issue 832](https://github.com/w3c/webextensions/issues/832): Spec clarification: TabId 0 |
| 104 | + |
| 105 | + * [simeon] *Note: moved this discussion up to give Harsh a chance to fix mic issues.* |
| 106 | + * [kiara] Added this as I think there was a follow-up from Chrome. |
| 107 | + * [oliver] Haven't had a chance to ask about this. |
| 108 | + |
| 109 | +[Issue 837](https://github.com/w3c/webextensions/pull/837): Proposal: close() Method for the sidePanel API |
| 110 | + |
| 111 | + * [oliver] First proposal is to add a close method to the sidepanel API. Already possible in Chrome by sending a message to the sidepanel and calling window.close(). |
| 112 | + * [timothy] Sounds good to me. |
| 113 | + * [tomislav] Same, supportive. |
| 114 | + * [harsh] Thinking about aligning change with the onClose event. Only specific topic to discuss was user gesture, but it sounds like we're aligned on not requiring one. |
| 115 | + * [carlos] What would happen if you have a global side panel open and you call close with a specific tabId? Would it throw? Close on a specific tab? |
| 116 | + * [harsh] The idea was to apply the change either globally or per-tab, as specified. |
| 117 | + * [oliver] I think we wouldn't want to introduce a new state. Now you can either have a single sidepanel or a global. I don't think we'd want to create the concept of global except for specific tabs. |
| 118 | + * [carlos] I'd be in favor of throwing as it clearly communicates to the developer that there's no single tab to close associated with that tab. |
| 119 | + * [oliver] I can work with Harsh to update the proposal to clarify this behavior. |
| 120 | + |
| 121 | +[Issue 838](https://github.com/w3c/webextensions/pull/838): Proposal: API to Query Side Panel Position |
| 122 | + |
| 123 | + * [harsh] We currently have left and right positions. Want to provide devs a way to get the current position. Also thinking about introducing getSettings for the side panel, so if the user wants to get more than the position the developer can get those fields. |
| 124 | + * [olivers] There's a question about how generalized this API should be. Don't think we want to only expose position left/right, as another browser could have other fields. Would at least want an object that other browsers could use to define more fields. |
| 125 | + * [harsh] Also thought about left/right using a boolean. For example, isLeft, isRight. Concern with using a string as other browser may have other values besides “left” and “right”. |
| 126 | + * [tomislav] Would suggest something more generic similar to Oliver's middle suggestion. |
| 127 | + * [timothy] Why not just match to an enum value? |
| 128 | + * [oliver] I think what we wanted to allow for was positioning information that's more detailed than a single string. Nothing specific in mind, but trying to cover things like positioning by x-y coordinates or anything that can't be represented by a single string. |
| 129 | + * [oliver] Seems there is general alignment on a getPosition() API which returns a dictionary, with a single key which is a string enum representing the position. |
| 130 | + * [kiara] I'll schedule some time on my end to do a more formal review. |
| 131 | + |
| 132 | +WPT Check-in |
| 133 | + |
| 134 | + * [tomislav] Saw that Devlin has added a comment, Timothy added a suggestion for test names. |
| 135 | + * [timothy] Just a clarification of Devlin's suggestion. The test on test sounded weird. |
| 136 | + * [tomislav] Kiara and I joined the Browser Testing and Tools sync, they asked us ping them in their #wpt:matrix.org chat once we get final approval from all browsers for faster processing. Channel. |
| 137 | + |
| 138 | +TPAC update |
| 139 | + |
| 140 | + * [timothy] Simeon and I got an email this morning from TPAC. We have until Jun 20, 2025 to request rooms for TPAC. Will coordinate with Simeon to get this submission filled out and submitted. |
| 141 | + |
| 142 | +Working Group update |
| 143 | + |
| 144 | + * [simeon] Oliver and I spent some time last week working on the draft charter. Oliver ran it by Chris Wilson at Google and he encouraged us to move forward. I’m going to run int by Tantek on my side. When I get a thumbs up from him, I’ll follow up with PLH. |
| 145 | + |
| 146 | +[PR 792](https://github.com/w3c/webextensions/pull/792) [carlos] Rob approved the onInvalidated (which was the only pending review), can we merge? |
| 147 | + |
| 148 | + * [oliver] Fine by me. I know both Devlin and I approved it a while back. |
| 149 | + * [tomislav] If Rob approved we're good on Firefox. |
| 150 | + * [simeon] Looks like Timothy already approved. I'll go ahead and click the button to merge. |
| 151 | + |
| 152 | +The next meeting will be on [Thursday, July 3rd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68671980,384). |
0 commit comments