Skip to content

Publish minutes of 2025-07-03 meeting #845

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.

Sign up for GitHub

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
Rob--W merged 1 commit into from
Jul 17, 2025
Merged

Publish minutes of 2025-07-03 meeting #845

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
171 changes: 171 additions & 0 deletions _minutes/2025-07-03-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,171 @@
# WECG Meetings 2025, Public Notes, July 3

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=68671980,384
Call-in details: [WebExtensions CG, 3rd July 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20250703T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #840](https://github.com/w3c/webextensions/issues/840), [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** (5 minutes)
* [Issue 844](https://github.com/w3c/webextensions/issues/844): Ad-Filtering Dev Summit 2025 ([@chrmod](https://github.com/chrmod))
* **Triage** (0 minutes)
* None
* **Timely issues** (15 minutes)
* Check in on event.composedPath() and retrieval of closed ([@Rob–W](https://github.com/Rob--W))
* [Issue 624](https://github.com/w3c/webextensions/issues/624): Proposal: getLeafTarget() method
* [Issue 815](https://github.com/w3c/webextensions/issues/815): Inconsistency: Retrieving closed shadow roots
* **Check-in on existing issues** (25 minutes)
* Google Summer of Code issue check-in ([@oliverdunk](https://github.com/oliverdunk))
* [Issue 838](https://github.com/w3c/webextensions/pull/838): Proposal: API to Query Side Panel Layout
* [Issue 779](https://github.com/w3c/webextensions/pull/779): Proposal for sidePanel lifecycle events
* [Issue 817](https://github.com/w3c/webextensions/pull/817): Proposal: Focus management API
* [Issue 116](https://github.com/w3c/webextensions/issues/116): Proposal: stop adding host_permissions from content_scripts
* [tomislav] WPT RFC, split out brower.test API part into our own note?
* https://github.com/web-platform-tests/rfcs/pull/219#issuecomment-3024535237


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Timothy Hatcher (Apple)
3. Krzysztof Modras (Ghostery)
4. David Johnson (Apple)
5. Oliver Dunk (Google)
6. Tomislav Jovanovic (Mozilla)
7. Simeon Vincent (Mozilla)
8. Carlos Jeurissen (Jeurissen Apps)
9. Harsh Singh (Google, Summer of Code)
10. Mukul Purohit (Microsoft)
11. Kiara Rose (Apple)
12. Casey Garland


## Meeting notes

[Issue 844](https://github.com/w3c/webextensions/issues/844): Ad-Filtering Dev Summit 2025

* [krzysztof] Announcing AFDS 2025 ([adfilteringdevsummit.com](https://adfilteringdevsummit.com/)), hosted by AdGuard and Ghostery, also sponsored by Eyeo. Event is in Cyprus, [call for papers is open](https://docs.google.com/forms/d/e/1FAIpQLSfA7C_1rP7HIa0iHVYk3qA7hMam-BJVMhqGSc85jN6L2orTwA/viewform).
* [oliver] Planning to attend.
* [rob] Not technically a WECG topic, but we can keep the issue open for visibility.
* [tomislav] Do you plan to have a browser session like previous years?
* [krysztof] We plan to, yes.

[Issue 624](https://github.com/w3c/webextensions/issues/624): Proposal: getLeafTarget() method

* And: [Issue 815](https://github.com/w3c/webextensions/issues/815): Inconsistency: Retrieving closed shadow roots
* [timothy] We recently landed openOrClosedShadowRoot in the dom namespace and Element DOM interface. We also updated event.composedPath() so that if you're in an extension context, we also include close shadow roots.
* [timothy] We previously discussed this topic and agreed that this would make more sense than a separate method getLeafTarget().
* [rob] On this issue, I see Chrome has a needs follow up label.
* [oliver] Still interested in doing this, and the approach makes sense. Thinking of a dictionary option. I'll add supportive:chrome label.
* [timothy] We could easily introduce an option.
* [oliver] We had a few different proposals we were planning to bring other groups to get more experience doing this. For example, changing the origin of a fetch request. That has been our priority. Planning to come back to this after.
* [oliver] Could we rename the issue for clarity, since we settled on a different method?
* [timothy] Yes, I'll edit the title.
* Renamed to: [Issue 624](https://github.com/w3c/webextensions/issues/624): Proposal: exposed closed shadow roots in event.composedPath()

[Issue 838](https://github.com/w3c/webextensions/pull/838): Proposal: API to Query Side Panel Layout

* [oliver] We've discussed this in previous meetings. Harsh is working on a few issues related to Google Summer of Code. On the side panel method to get layout, I think we had general consensus. Harsh, any specific questions?
* [harsh] no specific concerns at the moment.
* [carlos] Sidebar vs sidepanel not settled, should we be discussing this in the WECG?
* [simeon] We converged towards unifying the namespaces. In this case there is no equivalent for this concept in either namespace.
* [carlos] Would it make sense to add it to sidebar namespace for now.
* [rob] I think we were considering having sidebar be an alias to the combination of existing namespaces.
* [carlos] Fun fact: In Naver Whale browser sidepanel and sidebar_action are two different APIs
* [carlos] RTL vs LTR.
* [oliver] Do you mean what the preference is in the browser?
* [carlos] Could be.
* [david] In Safari, we flip the entire UI in RTL languages.
* [oliver] We looked at this on the Chrome side; we change the default only, but once opened, it will stick in that position even if the writing direction changes.
* [simeon] Maybe we need a way to query the browsers preferred writing direction?
* [rob] Out of scope for this API.
* [simeon] Potential API design concern. Developer may want to query based on whether the current position matches the writing direction settings of the browser. Of course, could be accomplished through other means.
* [carlos] Tab/window-specific positions?
* [oliver] Could discuss it. There's a chrome level setting that allows users to choose whether it's shared across windows.
* [rob] How would this work when the user switches sides, does it apply to all windows? E.g. an existing example of Devtools, when docked, it applies to the current sidebar and new ones, but the existing ones still stay in the current place.
* [oliver] We'd move them all.
* [timothy] Would be odd to have it switch sides as you switch tabs.
* [carlos] So basically we want the API to be based on the assumption that it's always the same across all tabs and browser windows.
* [timothy] I think that's best for now. Window ID might be a good option to consider down the road.
* [oliver] Do you have an implementation behind a flag in Safari?
* [timothy] Some initial work behind a flag, not ready to ship.
* [oliver] Is it enough to compare as we start work on an initial implementation?
* [timothy] I can take a look.

[Issue 779](https://github.com/w3c/webextensions/pull/779): Proposal for sidePanel lifecycle events

* [oliver] There was some discussion about the meaning of opening and closing, such as when you're switching tabs
* [harsh] Yeah, that was the main concern
* [oliver] Tentatively thinking the best way to approach this is to have open and close explicitly mean creation and destruction of the document. This would not cover visibility changes. If we wanted to in the future, we could introduce onshow and onhide events.
* [simeon] That makes sense to me. For the moment, extension developers can use page visibility APIs to check visibility changes and post messages back to the background.
* [oliver] I believe this was opened by someone at Microsoft. Mukul, could you add something about having these events only fire when the document is closed for good?
* [mukul] Can do.

[Issue 817](https://github.com/w3c/webextensions/pull/817): Proposal: Focus management API

* [oliver] As I recall, this was a bigger exploration of a number of ways we could approach this.
* [simeon] Where did we decide on sub frames in a document?
* [rob] Not focus on sub frames for now.
* [simeon] Will proceed with the assumption that we're only concerned with main frames.
* [krzysztof] Concern around changing focus to get access to user input. May need additional checks like activeTab or host permissions.
* [oliver] Definitely want to do additional privacy review. … For focusing specific frames, would want to better understand what's possible on the web. If it's already something you can do
* [krzysztof] What about invisible frames? Frames outside the viewport?
* [carlos] Can already open a popup to get input.
* [simeon] I think Krzysztof mentioned address bar focus – that's currently out of scope.
* [timothy] Could be a browser decision.
* [simeon] I'll try to rename the proposal to more clearly focus its intent.

[Issue 116](https://github.com/w3c/webextensions/issues/116): Proposal: stop adding host_permissions from content_scripts

* [carlos] https://github.com/w3c/webextensions/issues/116#issuecomment-3032370321
* Referencing [PR 798](https://github.com/w3c/webextensions/pull/798): Proposal "Allow to change permissions behavior on extension updates
* [carlos] Considering the discussion in PR 798, wonder if we could offer similar functionality to content_scripts, e.g. permissions_behavior.content_scripts.
* [tomislav] I think that this is a good idea overall. Concerned with making developers change existing implementations. Generally supportive.
* [rob] I think Carlos was suggesting adding a property to say what the behavior should be, not requiring duplication of keys (this is a new comment).
* [carlos] Yes, Would be an opt in by the developer. Potentially could change default in the next manifest version.
* [oliver] Definitely like the idea of a property, but less convinced in this case that we'd want to remove the property in the future.
* [timothy] I put supportive on this in the past, but at the moment I'm not sure how we'd inject it without host permissions being granted on that domain.
* [tomislav] Could have a content script that matches <all_urls> but you only want it to run on specific domains. First time it runs on a given domain, you ask for the permission.
* [timothy] Got it. That almost seems like a UI bug in the browsers, where if you're already asking for all host permissions, don't mention the individual domains that might be mentioned in content scripts.
* [tomislav] Not sure. I see value in explicitly saying “this script can run everywhere, but for now only run it on X.” Would allow you to declare a content script in the manifest that _could_ run anywhere, but doesn't have to.
* [rob] Is there anything actionable that we can do now given [Carlos' comment](https://github.com/w3c/webextensions/issues/116#issuecomment-3032370321)?
* [rob] The snippet references permissions_behavior, which is defined in another PR. Might make sense to integrate this use case on that one. Could be useful to help decide whether we proceed with “update_behavior” or “permissions_behavior”.
* [carlos] I think you were [commenting](https://github.com/w3c/webextensions/pull/798#issuecomment-2863660304) on using the update_behavior name.
* [rob] Yes, but no strong preference. Willing to consider all options.
* [carlos] Currently browsers try to decide how best to handle things based on the information provided by developers. Can make it had for developers to predict.
* [rob] Not sure how to proceed. Trying to read between the lines on what you're suggesting that browser should be doing. Specific naming and meaning could be more clear.
* [timothy] Including “matches” in there would help clarify.
* [rob] Should also think about what happens if a user later revokes permission or if the user doesn't grant permission in Safari / Firefox up to v127.
* [oliver] Actually having a proposal would be really helpful.
* [timothy] Agreed. Would help distill thoughts spread across comments into one cohesive explanation.
* [carlos] I thought that proposals should not just be aspirational and have a sponsoring browser.
* [rob] Shouldn't be too heavyweight. Goal is to help clarify what we're all thinking and considering.
* [timothy] Willing to be the sponsoring browser for the proposal from Carlos.
* [timothy] Has anyone else started looking at the permission behavior proposal ([PR 798](https://github.com/w3c/webextensions/pull/798))?
* [rob] Left some feedback on naming. I think Carlos did as well. Don't think it's been updated since then.
* [timothy] To be clear, not suggesting we combine them. Just seems odd to build on a proposal that hasn't been accepted.

[web-platform-tests/rfc PR 219](https://github.com/web-platform-tests/rfcs/pull/219): Add support for testing the WebExtensions API in WPT

* https://github.com/web-platform-tests/rfcs/pull/219#issuecomment-3024535237
* [tomislav] WPT RFC, split out brower.test API part into our own note?
* [tomislav] Quick update: saw that both Sam and James commented recommending that we split out browser.test into our own technical note. I want to do that and address some other issues identified by James in the process. Want to make sure Kiara and others are comfortable with this. Suggest Kiara takes on addressing Jame's comment re: bidi and I'll take the others.
* [kiara] Feedback we initially got was that they wanted some additional documentation about how we'd be using this in a separate document. The initial feedback was to include this info in the RFC since we didn't have it originally.
* [tomislav] I think they were suggesting we take what we already have and include it in the RFC. There was also a style note from James about present vs future tense.
* [kiara] There was also a comment about combining tests. Specifically, having runTests combine multiple tests and run them as one.
* [tomislav] I can address that.
* [rob] On the location of the browser.test thing, I've seen other specs make a note and include a link to an issue. To indicate that something is up for discussion, e.g. being moved elsewhere.
* [tomislav] I can do that. I'll create a PR patch for our repo and add a link.
* [oliver] Simeon, wonder if we should mention this in the WG charter.
* [simeon] Could do. I haven't read this discussion, but in prepping the WG charter I've looked over other group's charters and specs. Seems the typical approach is to have webdriver spec extensions defined in a subsection of a group's relevant spec doc.
* [tomislav] I think I understand your comment, but this isn't extending webdriver, it's defining the current behavior of browser.test.

The next meeting will be on [Thursday, July 17th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68798e80,384).
10 changes: 3 additions & 7 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,28 +10,24 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2025-06-19 - Cancelled due to Juneteenth in USA
- 2025-07-03 at 8 AM PDT = https://everytimezone.com/?t=68671980,384
- 2025-07-17 at 8 AM PDT = https://everytimezone.com/?t=68798e80,384
- 2025-07-31 at 8 AM PDT = https://everytimezone.com/?t=688c0380,384

## Past meetings

* 2025-07-03 ([minutes](2025-07-03-wecg.md))
* 2025-06-05 ([minutes](2025-06-05-wecg.md))
* 2025-05-22 ([minutes](2025-05-22-wecg.md))
* 2025-05-08 ([minutes](2025-05-08-wecg.md))
* 2025-04-24 ([minutes](2025-04-24-wecg.md))
* 2025-04-10 ([minutes](2025-04-10-wecg.md))
* 2025-03-28 F2F meetup in Berlin ([minutes](2025-03-28-berlin-f2f.md))
* 2025-03-27 ([minutes](2025-03-27-wecg.md))
* 2025-03-27 F2F meetup in Berlin ([minutes](2025-03-27-berlin-f2f.md))
* 2025-03-26 F2F meetup in Berlin ([minutes](2025-03-26-berlin-f2f.md))
* 2025-03-25 F2F meetup in Berlin ([minutes](2025-03-25-berlin-f2f.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2025**

* 2025-07-03 ([minutes](2025-07-03-wecg.md))
* 2025-06-05 ([minutes](2025-06-05-wecg.md))
* 2025-05-22 ([minutes](2025-05-22-wecg.md))
* 2025-05-08 ([minutes](2025-05-08-wecg.md))
Expand Down