-
Notifications
You must be signed in to change notification settings - Fork 60
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #753 from w3c/meeting-2025-01-30
Publish minutes of 2025-01-30 meeting
- Loading branch information
Showing
2 changed files
with
157 additions
and
2 deletions.
There are no files selected for viewing
This file contains 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,154 @@ | ||
| # WECG Meetings 2025, Public Notes, Jan 30 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=679ac100,384 | ||
| Call-in details: [WebExtensions CG, 30th January 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250130T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #751](https://github.com/w3c/webextensions/issues/751), [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) | ||
| * [rob] FOSDEM | ||
| * **Triage** (15 minutes) | ||
| * [Issue 749](https://github.com/w3c/webextensions/issues/749): Proposal: Support a shared state for tab groups | ||
| * **Timely issues** (10 minutes) | ||
| * [Issue 752](https://github.com/w3c/webextensions/issues/752): Proposal: New sidePanel.onClosed event for the sidePanel API | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
| * [PR 729](https://github.com/w3c/webextensions/pull/729): Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events | ||
| * [PR 542](https://github.com/w3c/webextensions/pull/542): Add content scripts section in specification | ||
| * [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Giorgio Maone (NoScript, Tor) | ||
| 3. Oliver Dunk (Google) | ||
| 4. Timothy Hatcher (Apple) | ||
| 5. Tomislav Jovanovic (Mozilla) | ||
| 6. Krzysztof Modras (Ghostery) | ||
| 7. Casey Garland (Capital One) | ||
| 8. Simeon Vincent (Mozilla) | ||
| 9. Patrick Kettner (Google) | ||
| 10. Carlos Jeurissen (Jeurissen Apps) | ||
| 11. Todd Schiller (PixieBrix) | ||
| 12. Mukul Purohit (Microsoft) | ||
| 13. Sohail Rajdev (Microsoft) | ||
| 14. Jordan Spivack (Capital One) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| FOSDEM | ||
|
|
||
| * [rob] Several of us are meeting at FOSDEM this weekend in Brussels. Including a session on Saturday where were are going to discuss WebExtensions. Come join us! https://fosdem.org/2025/schedule/event/fosdem-2025-5916-webextensions-bof/ | ||
| * [oliver] FOSDEM does not require any tickets; other than requiring booking of travel at the last minute, there are no further requirements. | ||
|
|
||
| [Issue 749](https://github.com/w3c/webextensions/issues/749): Proposal: Support a shared state for tab groups | ||
|
|
||
| * [oliver] We are working on a Chrome feature where users are able to share a tab group. Changes to a tab group will be reflected in tab groups of those with whom the tab group is shared. | ||
| * [timothy] No objections from my part. | ||
| * [simeon] This proposal introduces a `shared` boolean. Is there any intention/desire to allow extensions to be involved in sharing the tab group? | ||
| * [oliver] Not aware of any; I know that we had (temporary) restrictions in the initial implementation, e.g. to prevent extensions from triggering many changes that the system did not account for. | ||
| * [krzysztof] Is there a need for a permission? E.g. to counter concerns that a user's tab group is leaked to another user. | ||
| * [rob] This request here just exposes the information about whether the tabgroup is shared, there is no API to manage tab groups. Looks good to me. | ||
| * [oliver] Exactly. Even without this proposal, the tab group is known, but extensions would not know whether it is shared. | ||
| * [krzysztof] And privacy-aware extensions can choose to ignore shared tab groups. | ||
|
|
||
| [Issue 752](https://github.com/w3c/webextensions/issues/752): Proposal: New sidePanel.onClosed event for the sidePanel API | ||
|
|
||
| * [timothy] Appears to be a duplicate of [issue 517: sidePanel API: lifecycle events](https://github.com/w3c/webextensions/issues/517). Originally we punted on the discussion since it was chrome-only; since then we started the development of sidePanel API (and sidebar_action), but that has stalled recently. I am in favor. | ||
| * [oliver] We are in favor. | ||
| * [simeon] Would it make sense to introduce an onUpdated instead of separate events? | ||
| * [rob] Please don't. tabs.onUpdated is an example of an event that is too noisy. | ||
| * [simeon] And with filters? | ||
| * [timothy] Extensions have historically not used filters much. | ||
| * [todd] Would this be a listener in the background or in a content script? Getting current status for isOpen or isClosed is generally needed in the content script and there's inherent raciness to needing to query the background. | ||
| * [timothy] It would be a typical event in extension contexts, likely broadcast tabId. | ||
| * [todd] Some browser specific behavior: Edge auto-closes for some UX patterns. | ||
| * [mukul] We are aware of that, and thinking of bridging that with the Chrome implementation. | ||
| * [todd] What permissions would be needed? Opening sidebar programmatically without user gesture requirement. Chrome's current implementation seems buggy. | ||
| * [rob] Why would we need permissions for an event? | ||
| * [todd] Thinking similar to tabs permission, where there are certain properties on objects that require the permission to read. | ||
| * [rob] Similar case with the action API where you can check if it's enabled or disabled. Sounds like we're generally in favor of this. Since it's a duplicate, should we continue with this issue or mark it as a duplicate? | ||
| * [timothy] In favor of marking as a duplicate. | ||
| * [oliver] Right now in Chrome, you have to request the “sidePanel” API to use the sidePanel API. We're not using the permission due to particular events, it is just part of exposing the API. | ||
| * [simeon] I like an explicit declaration in the permission request. | ||
| * [timothy] Likewise. | ||
| * [rob] On actionable tasks - currently we are about to mark the issue as a duplicate. The original issue does not have actionable tasks, but it looks like there is developer interest in this. What are the next steps? | ||
| * [todd] I'm willing to help with a proposal. | ||
| * [mukul] We can collaborate with that, at least onClosed. | ||
| * [oliver] Do we need a proposal for a single event? | ||
| * [rob] Just a single event, not needed, but in this case the broader issue is the full lifecycle, and it would make sense to think about this more holistically. | ||
|
|
||
| [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
|
|
||
| * [giorgio] The main objection on the issue seems that service workers are not associated with a specific tab ID. We (NoScript, Tor browser, JShelter) are comfortable with that. Matching on the page spawning the worker or the actual URL where the worker is executed, that would be fine for us. | ||
| * [oliver] To clarify, the option we were in favor of is the URL/origin where the worker script is at. | ||
| * [giorgio] One wrinkle is that workers can be spawned from data/blob. We are not interested in data/blob, but the actual origin that spawned the worker. | ||
| * [oliver] Would match_origin_as_fallback work in this case? | ||
| * [rob] Yes. | ||
| * [giorgio] That behavior works for us. If we could optionally have the tabId, that would be nice. | ||
| * [timothy] Not able to support tabId, as shared workers / service workers can apply to multiple tabs. | ||
| * [giorgio] It is OK to not support tabId; we have work-arounds. | ||
| * [timothy] This one calls out registerContentScripts, I would want it to be added to the manifest content_scripts key if supported too. | ||
| * [krzysztof] Also important for adblockers to be able to target workers. Some sites use workers to fetch ads. | ||
| * [timothy] Would <all_urls> match workers? | ||
| * [rob] With match_origin_as_fallback, yes. | ||
| * [krzysztof] Also want to be able to target origin-less URLs. | ||
| * [rob] Do you want to match data:-URLs separately? | ||
| * [krzysztof] Typical use case is to get all workers spawned by a given origin. | ||
| * [rob] Sounds like Safari is supportive. I don't see objections on Firefox side. Chrome? | ||
| * [oliver] Need follow up with Chrome engineering. | ||
| * [rob] Also ties into content script section of the spec that Oliver is raising later (https://github.com/w3c/webextensions/pull/542). | ||
| * [timothy] Giorgio, are you interested in a proposal? | ||
| * [giorgio] Should we merge this with the existing PR? | ||
| * [rob] No, no current spec exists and this is introducing new capabilities. It would be best to draft a separate proposal. | ||
| * [oliver] Also questions about what APIs to support. | ||
| * [giorgio] Scripts executed in the worker should not need access to extension APIs. | ||
| * [rob] I was also going to propose limiting to MAIN world only; exposing extension APIs has significant complexity. | ||
| * [giorgio] Comfortable with that. | ||
|
|
||
| [PR 729](https://github.com/w3c/webextensions/pull/729): Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events | ||
|
|
||
| * [timothy] Got a couple approvals, waiting for one more. | ||
| * [rob] I reviewed before, and called out a concern with split incognito mode. | ||
| * [sohail] Seemed to be general consensus around firing events separately. I updated the proposal accordingly. No additional notes. | ||
| * [timothy] Removing old events in next manifest version bump might be good so we're not duplicating events. | ||
| * [sohail] Makes sense. | ||
| * [krzysztof] Would you be open to something like onDisabledUrl. Would be useful for things like the MV2 deprecation in Chrome where the user does not have direct control over that action. | ||
| * [timothy] Worthy of a new issue for discussion. We don't support setUninstallURL in Safari because we do currently not have a good way to detect it in Safari. | ||
| * [rob] PR notes that the event may fire separately. In split incognito mode, to the extension that looks like a fresh installation. | ||
| * [oliver] Didn't we already agree that we should fire the onEnabled event in this case? | ||
| * [rob] If we did, that's fine. Let's explicitly call that out in the proposal. | ||
|
|
||
| [PR 542](https://github.com/w3c/webextensions/pull/542): Add content scripts section in specification | ||
|
|
||
| * [timothy] Would love to see this merged. | ||
| * [rob] I reviewed this a few days ago. | ||
| * [oliver] Rob had good feedback, I've updated the PR. Using “precursor origin”, but it is not well-defined. | ||
| * [rob] The concept of a precursor origin exists in Firefox and Chrome. Does that exist in Safari? | ||
| * [timothy] It is a foreign concept to me, I have to look it up. | ||
| * [simeon] Start with specifying it in the extension spec. | ||
| * [rob] Fine by me - in the review I suggested putting a placeholder in the extension spec, and update the reference later if there is ever a specification of this concept elsewhere. | ||
|
|
||
| [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API | ||
|
|
||
| * [rob] On the PR the PR author and Mozillians are discussing with each other. Are there blockers on Safari or Chrome's side? | ||
| * [timothy] No objections on my side. I will take another look. | ||
| * [oliver] Looked at it when it first opened and generally looked good to me. Once it's in a good state, happy to pass it along to eng for review. | ||
| * [simeon] Is it in a good state for that now, Rob? | ||
| * [rob] There is a general sentiment that we should do this, but the finer details of the API are still being worked out. Once that completes it should be ready for a final review. | ||
| * [krzysztof] Shouldn't this be part of the web? | ||
| * [rob] I believe there's been strong hesitation from some browser vendors, particularly Chrome, around exposing the PSL more broadly. | ||
| * [oliver] Maintainers of the PSL are very concerned about broadening the use of the PSL, as that may result in more people wanting to get entries on the PSL. | ||
|
|
||
| The next meeting will be on [Thursday, February 13th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=67ad3600,384). |
This file contains 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