Skip to content

Publish minutes of 2025-05-08 meeting #823

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
merged 1 commit into from
May 9, 2025
Merged

Publish minutes of 2025-05-08 meeting #823

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
163 changes: 163 additions & 0 deletions _minutes/2025-05-08-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,163 @@
# WECG Meetings 2025, Public Notes, May 8

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=681bf400,384
Call-in details: [WebExtensions CG, 8th May 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250508T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #819](https://github.com/w3c/webextensions/issues/819), [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)
* **Triage** (15 minutes)
* [Issue 820](https://github.com/w3c/webextensions/issues/820): Ability to define an alternative toolbar icon visual when an allowAllRequests DNR rule is in effect in top frame
* [Issue 821](https://github.com/w3c/webextensions/issues/821): websites.thirdPartyCookiesAllowed can provide misleading information to developers
* [PR 822](https://github.com/w3c/webextensions/pull/822): Proposal: privacy.websites.thirdPartyCookiesAccessible
* **Timely issues** (10 minutes)
* [PR 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification
* **Check-in on existing issues** (20 minutes)
* [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API
* [PR 817](https://github.com/w3c/webextensions/pull/817): Proposal: Focus management API
* [PR 798](https://github.com/w3c/webextensions/pull/798): Proposal "Allow to change permissions behavior on extension updates"
* [PR 779](https://github.com/w3c/webextensions/pull/779): Proposal for sidePanel lifecycle events.
* [PR 802](https://github.com/w3c/webextensions/pull/802): Add proposal for topFrameMatches and excludeTopFrameMatches
* [PR 799](https://github.com/w3c/webextensions/pull/799): Add browser.permissions.canAccess() proposal


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. David Johnson (Apple)
3. Timothy Hatcher (Apple)
4. Philippe Le Hegaret (W3C)
5. Aaron Selya (Google)
6. Oliver Dunk (Google)
7. Giorgio Maone (NoScript, Tor)
8. Mukul Purohit (Microsoft)
9. Carlos Jeurissen (Jeurissen Apps)
10. Simeon Vincent (Mozilla)
11. Tomislav Jovanovic (Mozilla)
12. Oleksii Levzhynskyi (Grammarly)


## Meeting notes

Question about WG charter status.

* [philippe] Did you discuss WG charter during the Berlin meeting?
* [rob] We did, https://github.com/w3c/webextensions/pull/814 contains table of contents and action items, one of the action items is “Oliver to drive finishing draft of charter for WG”. Full meeting notes is at [\_minutes/2025-03-27-berlin-f2f.md , section "WG Discussion"](https://github.com/w3c/webextensions/blob/main/_minutes/2025-03-27-berlin-f2f.md#wg-discussion)
* [oliver] We're working on it.
* [philippe] Ping me when you have something.

[Issue 820](https://github.com/w3c/webextensions/issues/820): Ability to define an alternative toolbar icon visual when an allowAllRequests DNR rule is in effect in top frame

* [timothy] Content blocking extensions would like a custom icon where DNR is disabled for the top level frame. Suggestion is to add a new option to the existing declarativeNetRequest.setExtensionActionOptions method to allow a custom icon to be specified when allowAllRequests is in effect.
* [timothy] I think it's reasonable and feasible. There is precedent for badging
* [oliver] I'll check with Devlin, but it sounds reasonable to me.
* [rob] Unlike “block” DNR actions, where the outcome is final, the “allowAllRequests” action is more of a “ignore rules below a certain priority”. It is not very obvious what ought to happen, e.g. another extension can also decide to block/modify a request independently of the original extension.
* [rob] Would you consider a new DNR action that would set the action icon? Comparable to Chrome's declarativeContent.SetIcon action.
* [rob] Next step is for interested parties to come up with a proposal (does not have to be a formal proposal, a comment on the issue works too). The proposal should define precisely what the expected behaviors are, so that we can evaluate whether this is something that can feasible be implemented or generalized.

[Issue 821](https://github.com/w3c/webextensions/issues/821): websites.thirdPartyCookiesAllowed can provide misleading information to developers

* [aaron] Right now, there is a Chrome-only API websites.thirdPartyCookiesAllowed that reveals the browser settings of whether third-party cookies are blocked or not, but that may not be accurate for individual frames. I think that it makes sense to add an API that exposes whether an individual frame has access to third-party cookies. I created a PR:
* [PR 822](https://github.com/w3c/webextensions/pull/822): Proposal: privacy.websites.thirdPartyCookiesAccessible
* [tomislav] Can't a web page be used in a content script?
* [aaron] It is possible (Storage Access API), but requires host access to the websites.
* [tomislav] If this already exists on the web platform, do we need a new extension API?
* [timothy] One question I have, is this the right place? We currently don't have the privacy namespace. Maybe new API should be elsewhere.
* [rob] cookies API would be a very natural choice.
* [aaron] Problem with that is that the “cookies” permission would be required.
* [rob] cookies permission does not have a permission warning.
* [aaron] Ah okay.
* [oliver] Explain tri-state return value?
* [aaron] Matches storage access API statuses.
* [rob] If the intent is to mirror the storage access API, can we use a similar name and defer to that API?
* [aaron] Potentially other sources that affect the outcome, e.g. enterprise policies. Naming the API after storage access may be too tight coupling.
* [aaron] I'll update the PR.
* [rob] And please clarify what the use cases are and why it cannot be achieved with existing APIs.

[PR 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification

* [tomislav] We rarely use trial tokens, not currently supported. Need to investigate if we can use this for extensions. Got preliminary approval to use it, but will try to conclude those discussions in the next 2 weeks.

[PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API

* [rob] Direction of recent discussions is to provide a get and parse method. Wondering if the use case are fully supported by this more limited API. There's some outstanding conversation on the issue that needs to be resolved, but it looks like it might be wrapping up soon.
* [oliver] I've been following along with email notifications.
* [timothy] I've been lurking and everything seems to go in the right direction?
* [rob] Do Oliver and Timothy have opinions or do you need to more fully review it?
* [timothy] Direction looks reasonable. I wasn't getting involved because of too many cooks in kitchen.
* [oliver] Same. There were discussions that got deep into questions like what does or doesn't count as an IP address, but the conversation went towards simplification, which looks good.

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

* [simeon] Some discussions since original proposal. Original proposal was to add a tabs.focus() API for all, but following feedback, the better approach seems to add focus() methods to individual namespaces for specific surfaces.
* [rob] tabs.focus() still kept for tabs, right?
* [simeon] Correct.
* [simeon] Question - use cases for focusing subframes of a document. Original use case is switching between sidebar and tab. Is there an additional benefit/use case for focusing a specific subframe?
* [timothy] I think that there would be use cases. E.g. a password manager inserting a frame in the page and wanting to focus it for a specific reason.
* [oleksii] User clicks on some button and then scrolls to a specific area.
* [rob] Relevant question. Focusing a tab implies that the viewport is visible (except possibly if the window is in the background). Focusing a frame might result in the desire to focus something outside of the (visible) viewport.
* [timothy] Focus is often autoscrolled in WebKit, that might be controllable as well.
* [simeon] Does tabbing to content autoscroll?
* [timothy] Possibly not when the JS API is used.
* [simeon] Hesitation on including scrolling is that we typically focus in exactly what's needed.
* [rob] That's why in previous discussions on this, I recommended to focus on focusing the tab (whatever that was last focused), instead of including specific frames.

[PR 798](https://github.com/w3c/webextensions/pull/798): Proposal "Allow to change permissions behavior on extension updates"

* [timothy] I've reviewed and approved; we're looking for feedback from other folks. (checking sponsoring browser) Firefox is the sponsoring browser.
* [rob] Yes, I'll review again.
* [oleksii] One question: I thought about the proposal, and it sounds like a new property may not be backwards-compatible. Have to wait for all users to update.
* [timothy]
* [simeon] Is it not backwards compatible? Do the behavior of old versions need to change? If the extension is disabled, you don't get the benefit of the new feature.
* [oleksii] Devs would still wait for a year before they can use it.
* [simeon] Having this field doesn't suddenly break old browsers, do they?
* [rob] you don't have a disadvantage to having it. Uses get the benefit in the new browsers. Usually when you say “backwards incompatible” it signals a disadvantage to older browsers.
* [oliver] There may be alternative proposals that don't have this issue. Example (not necessarily what I like, but for illustration): A new property that specifies new permission that if recognized should be retreated as a required permission / optional on update. Old browsers would not recognize this. Not as clean of an API design though.
* [oleksii] Probably makes sense to proceed with this proposal. Cleaner, easier for developers to understand and use moving forward. The “hybrid_permissions” key wasn't clear.
* [rob] Next steps: Chrome and Firefox to review the proposal.

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

* [mukul] Need signoffs and reviews.
* [rob] Why is the “path” included in PanelOpenInfo / PanelCloseInfo?
* [mukul] Will have to check if there was a specific requirement that motivated this property. I can see how it might be more information than is necessary.
* [rob] Might be helpful if you describe expected events for various scenarios. Examples scenarios and order of events. For example, if a sidePanel is tab-specific, and the user switches from one tab to another, would onClosed fire, followed by onOpen?
* [oliver] Checking the notes from our last discussion, Devlin indicated he'd want to have onClosed and onHidden.
* [rob] What's the difference?
* [oliver] onHidden is when it's no longer visible but the document still exists. onClosed is when the user explicitly closes the panel.
* [rob] Would be useful if the use cases provide the motivations for the events. At a high level it makes sense, but when looking at the individual events it's not clear if they provide enough information to address the use case.
* [Mukul] Oliver, will you take a look for Chrome?
* [oliver] I think that it makes sense to wait until the proposal has a bit more detail.

[PR 802](https://github.com/w3c/webextensions/pull/802): Add proposal for topFrameMatches and excludeTopFrameMatches

* [carlos] in addition to this API, introducing <extension_urls> match pattern would be very helpful to restrict content scripts to subframes inside extensions only. This is important as the extension origin is not known on installation and can vary on reload in Safari. Can follow up with a separate issue.
* [rob] We've discussed this and it looks sensible. The issue has “supportive” from all browsers. I need to take another look and provide feedback
* [oliver] There's also [issue 762](https://github.com/w3c/webextensions/issues/762): DNR: Add excludedTopFrameDomains (and topFrameDomains)
* [oliver] Both issues were opened by Polywock on the same day, one is about content scripts and the other is about DNR.
* [oliver] CL: https://chromium-review.googlesource.com/c/chromium/src/+/4145958
* [rob] Is there a reason for it being domains instead of match patterns in the DNR API?
* [oliver] Match patterns would be a bit weird, wouldn't it?
* [rob] Main question is whether there is a need for schemes.
* [timothy] Reluctant to introducing match patterns in DNR if there is no need for it. Domains fit with existing properties.
* [rob] I'm also good with domains in DNR, just wasn't sure if schemes should or shouldn't be supported. Non-blocking consideration. Just raised out of curiosity.
* [timothy] In practice Safari only supports the http-family of schemes.
* [tomislav] Carlos mentioned before about extension origins.

[PR 799](https://github.com/w3c/webextensions/pull/799): Add browser.permissions.canAccess() proposal

* [carlos] canAccess - question for Firefox folks on different behaviors for temporary host permissions, whereas in Firefox only scripts can be injected. Apple suggested to align with Chrome. Question whether Firefox can align as well.
* [tomislav] Technically hard to align. Can't just expose it because we don't currently track it internally in an appropriate way. Don't know if we can commit to the proposal right now.
* [rob] It's not impossible, but someone needs to do the work. Is our position that we are willing to align?
* [tomislav] Yes.

The next meeting will be on [Thursday, May 22nd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=682e6900,384).
5 changes: 3 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2025-05-08 at 8 AM PDT = https://everytimezone.com/?t=681bf400,384
- 2025-05-22 at 8 AM PDT = https://everytimezone.com/?t=682e6900,384
- 2025-06-05 at 8 AM PDT = https://everytimezone.com/?t=6840de00,384

## Past meetings

* 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))
Expand All @@ -24,13 +25,13 @@ After the end of each meeting, meeting notes are published here.
* 2025-03-25 F2F meetup in Berlin ([minutes](2025-03-25-berlin-f2f.md))
* 2025-03-13 ([minutes](2025-03-13-wecg.md))
* 2025-02-27 ([minutes](2025-02-27-wecg.md))
* 2025-02-13 ([minutes](2025-02-13-wecg.md))

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

**2025**

* 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))
Expand Down