From 3740adb06a4db7a4c78e390b15a3fad00b96a238 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Thu, 7 Nov 2024 18:30:39 +0100 Subject: [PATCH] Publish minutes of 2024-11-07 meeting --- _minutes/2024-10-24-wecg.md | 40 ++++++++ _minutes/2024-11-07-wecg.md | 186 ++++++++++++++++++++++++++++++++++++ _minutes/README.md | 10 +- 3 files changed, 232 insertions(+), 4 deletions(-) create mode 100644 _minutes/2024-10-24-wecg.md create mode 100644 _minutes/2024-11-07-wecg.md diff --git a/_minutes/2024-10-24-wecg.md b/_minutes/2024-10-24-wecg.md new file mode 100644 index 00000000..a4fe4895 --- /dev/null +++ b/_minutes/2024-10-24-wecg.md @@ -0,0 +1,40 @@ +# WECG Meetings 2024, Public Notes, Oct 24 + + * Chair: Simeon Vincent + * Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=67198e00,384 +Call-in details: [WebExtensions CG, 24th October 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20241024T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #709](https://github.com/w3c/webextensions/issues/709), [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) + * MEETING CANCELED, MOST FOLKS ARE OUT (AD-FILTERING DEV SUMMIT) + * **Triage** (15 minutes) + * (topics will move to the 7 nov meeting) + * [Issue 708](https://github.com/w3c/webextensions/issues/708): Cache Partitioning, HTTP Cache Management, and Conditional DNR Rule Application + * [Issue 711](https://github.com/w3c/webextensions/issues/711): Proposal: Enable changing the permissions for only new user + * **Timely issues** (10 minutes) + * **Check-in on existing issues** (20 minutes) + + +## Attendees (sign yourself in) + + 1. Rob Wu (Mozilla) + 2. Tomislav Jovanovic (Mozilla) + + +## Meeting notes + +Meeting canceled + + * [rob] Many of the usual Google and Mozilla representatives are currently absent because they are at the [Ad Filtering Dev Summit](https://adfilteringdevsummit.com/). At this exact time, Google folks are presenting “What's new in Chrome”. These sessions are recorded and will be published to Eyeo's YouTube channel. + * [tomislav] Canceled due to most folks being out. + +The next meeting will be on [Thursday, November 7th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=672c0300,3c0). Warning: daylight saving time changes between today and the next meeting. Still 5 PM in Europe. diff --git a/_minutes/2024-11-07-wecg.md b/_minutes/2024-11-07-wecg.md new file mode 100644 index 00000000..0856b5f1 --- /dev/null +++ b/_minutes/2024-11-07-wecg.md @@ -0,0 +1,186 @@ +# WECG Meetings 2024, Public Notes, Nov 7 + + * Chair: Simeon Vincent + * Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=672c0300,3c0 +Call-in details: [WebExtensions CG, 7th November 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20241107T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #718](https://github.com/w3c/webextensions/issues/718), [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) + * None + * **Triage** (25 minutes) + * [Issue 708](https://github.com/w3c/webextensions/issues/708): Cache Partitioning, HTTP Cache Management, and Conditional DNR Rule Application + * [Issue 711](https://github.com/w3c/webextensions/issues/711): Proposal: Enable changing the permissions for only new user + * [Issue 713](https://github.com/w3c/webextensions/issues/713): Should tabs.Tab.lastAccessed be optional? + * [Issue 715](https://github.com/w3c/webextensions/issues/715): Feature request: Enhance the tab group api to support the new pinning functionality + * [Issue 716](https://github.com/w3c/webextensions/issues/716): Inconsistent support for [context]menus.getTargetElement() + * [Issue 717](https://github.com/w3c/webextensions/issues/717): Request: [ContextMenus] Include ``s in the "page" ContextType (or it's own ContextType) + * [Issue 719](https://github.com/w3c/webextensions/issues/719): Adding a temporary listener just for the current run of the service worker or event page so it doesn't wake up next time for this event + * **Timely issues** (10 minutes) + * [Issue 527](https://github.com/w3c/webextensions/issues/527): chrome.scripting.executeScript doesn't resolve/reject for frozen state tabs + * [PR 546](https://github.com/w3c/webextensions/pull/546): update window.browser spec per #532 + * **Check-in on existing issues** (10 minutes) + * None + + +## Attendees (sign yourself in) + + 1. Simeon Vincent (Mozilla) + 2. Rob Wu (Mozilla) + 3. Aaron Selya (Google) + 4. Timothy Hatcher (Apple) + 5. Oliver Dunk (Google) + 6. Carlos Jeurissen (Jeurissen Apps) + 7. Patrick Kettner (Google) + 8. Steven McLintock (1Password) + 9. Cameron Eckelberry (Malwarebytes) + 10. Tomislav Jovanovic (Mozilla) + 11. Kiara Rose (Apple) + 12. Mukul Purohit (Microsoft) + + +## Meeting notes + +[Issue 708](https://github.com/w3c/webextensions/issues/708): Cache Partitioning, HTTP Cache Management, and Conditional DNR Rule Application + + * [oliver] Multiple questions here. Overall use case is wanting to have a custom PDF viewer. Rather than redirecting as some pages do, this extension injects an extension frame from a content script. Their approach faces challenges caused by cookie partitioning. Perhaps the issue should be broken down. + * [rob] Don't think we need to break down this issue. Root cause is that it's not possible to select which partition will be used to make a request. There are some not well documented mechanisms available in Chrome. It would be nice if there was a way to make a request from the right partition. + * [simeon] I believe we've discussed a way of selecting a partition to make a request before. Aaron may have some additional thoughts. + * [aaron] Specifically selecting the partition for a frame? Within the cookies API, we are defining the cookies.getPartitionKey method to retrieve the partition for a frame, including the topLevelSite and hasCrossSiteAncestor. + * [rob] That would provide a way to query the partition,but doesn't give us a way to specify the partition for a given request. I see two approaches: make sure the extension iframe is loaded in the right partition. Another is to provide a dedicated API for the extension to make a request from a given partition. Need to get feedback from browser vendors on preferred approach. + * Firefox bug that requests the capability to send requests associated with a specific partition: https://bugzilla.mozilla.org/show_bug.cgi?id=1670278 + * [oliver] In this case, the third-party context is a frame. In the extension document there's an iframe with a third party site. You'd want to change which partition that embedded frame uses. + * [patrick] In this case it's specifically an embedded frame from the Adobe CDN. + * [rob] In that case I don't think we should allow it to select a different partition, because that iframe is regular web content. + * [aaron] Sounds like requestStorageAccess would be useful for this. Inside the frame the extension could call this. If the cookie is a third party unpartitioned cookie we could potentially provide access to that. This is an area I work with often. requestStorageAccess is a purely JS API. As long as the iframe can use JS it could use this. We can follow up. + * [oliver] Might be best to post on the issue. That said, not purely a cookies issue. They're looking to apply DNR rules. Doesn't seem like this is the ideal way to solve this for the general case. + * [rob] I'd be strongly against providing this capability in DNR as it could inadvertently leak cookies across partitions. + * [patrick] I agree with Oliver's point of view, where there are more direct ways to handle the use case. E.g. Chrome's internal mimeHandlerPrivate API. + * [timothy] I'm also leaning towards that approach. There are too many work arounds. I'm sure more would be necessary if we go down this path. + * [rob] I'd also be in favor of a dedicated mimehandler API. Doesn't solve the general need to make requests from different partitions. + * [patrick] Oliver, do you have a sense of how people feel about the current mime handler? + * [oliver] No context on the current API. I think generally we've been favorable toward this type of functionality. As far as the specific API shape I'm not sure. + * [patrick] I'll be meeting with Adobe shortly. Happy to relay this conversation. + +[Issue 711](https://github.com/w3c/webextensions/issues/711): Proposal: Enable changing the permissions for only new user + + * [simeon] Browsers have different ways to handle new permissions; generally users have to consent to new permissions before the extension is updated. This presents challenges at converting users from an old version to a new version. Request here is to not automatically grant permissions on update. + * [simeon] My immediate thought is that if optional_permissions is an acceptable approach, why not use that? + * [rob] Agreed. + * [patrick] Ideally they would like it to not be optional, but don't want to disable the extension for existing users. + * [rob] For context, in Chrome new permissions cause the extension to be disabled. In Firefox the new version requires confirmation, but the old version continues working. + * [timothy] In Safari host permissions do not trigger anything, they are always optional in Safari. API permissions are often not warning, except in some cases, in which case the extension is disabled like Chrome (e.g. webNavigation). + * [tomislav] The result of the proposal would be a new kind of state where the extension in installed and working but doesn't have access to all the required permissions from the manifest. If we want to open that can of worms, that can be useful for other things as well. That would require extensions to code against that. So far the presumption has been that if it's a required permission it's always available. This would break that model. + * [timothy] I'm also concerned that developers won't checking permissions.contains() at runtime. + * [patrick] Nobody requested this as the default behavior, opt in is preferred. + * [simeon] The current model assumes required permissions are granted. If they can sometimes be optional, developers will need to approach all permissions added after the first public release as potentially optional. Can no longer guarantee that a required permission has been granted. + * [patrick] Impression I got was that this would be an upgraded permission. A fresh install would treat the permission as required. Permissions would only be treated as optional in an upgrade. + * [simeon] Extensions should develop as if all permissions are optional. Safest to assume required permissions may not be granted and code defensive. If this contract changes, no guarantee that the contract with the platform won't change further and the “required” permissions won't be treated as optional in the future. + * [rob] I'm aware that this is an issue that extension developers are facing. What is the appetite from browser vendors to implement solutions to the issue here? + * [patrick] This is a frequently recurring issue. + * [carlos] I've also had this issue in the past: you introduce something for a subset of users and it causes challenges for all users. + * [tomislav] On the Firefox side we've been discussing some related permissions issues around what's required or optional. Would be interested in further discussion. + * [simeon] No objections, but concerned about changes to the underlying model. + * [rob] Example of prior art in Firefox is the devtools manifest key. In Firefox you can add devtools as an optional permission in order to opt out of it as being required. We could do something similar and add a new manifest key that allows this kind of upgrade in a backwards-compatible way, as an example. From the API point of view there are multiple approaches, it is primarily a question of prioritization. This issue seems to be most pressing in Chrome. + * [patrick] Add chrome:follow-up and see if Devlin is interested in it. + +[PR 546](https://github.com/w3c/webextensions/pull/546): update window.browser spec per #532 + + * [patrick] Timothy, can you take a look at the PR that addresses [issue 532](https://github.com/w3c/webextensions/issues/532) (nuances of aliasing chrome and browser)? + * [timothy] Will do. + * [rob] Oliver approved the PR. I approved as well, now it just needs to be reviewed by Timothy (Apple) as well. + * [timothy] I'll approve today. + +[Issue 713](https://github.com/w3c/webextensions/issues/713): Should tabs.Tab.lastAccessed be optional? + + * [oliver] There's a lastAccessed property on the Tab object. For a long time this was Firefox only, but we recently added support in Chrome. The semantics of how it's set is a bit inconsistent. My assumption was that when you first access it this field would be undefined, but Firefox sets it on tab creation. + * [rob] What is the impact of marking it as optional or not? + * [simeon] My understanding was this was more about a behavior change – that when a tab is created the value is undefined. + * [oliver] If Firefox's behavior to always set it is intentional, then Firefox could mark it as not optional. + * [timothy] We haven't implemented this in Safari yet. Open to going with the consensus approach. + * [simeon] I haven't found any specific reason for the current implementation. When I first saw this I assumed that `undefined` would be used; seems like an intuitive default. The current behavior is to set the timestamp at creation surprised me. + * [tomislav] There is no discussion about optionality at introduction; I guess that we marked is as optional because it was Firefox-only at that time and not available in all browsers. Willing to mark it non-optional. + * [oliver] Would you be willing to defer setting it until the tab has been accessed? + * [rob] Could you come up with a specification of what you want it to be in all relevant scenarios? Then we can evaluate the request on that basis instead of just wondering whether it is set or not. + * [oliver] I can follow up and leave a comment on the issue. + * [simeon] I'd suggest using `0` over `undefined`. It's falsey, it's a valid value for new Date(), it continues having the property be defined on the object. Most consistent with how this value may be used in the ecosystem. + * [timothy] What about NaN? + * [rob] Produces an Invalid Date. + * [timothy] Right, NaN is kind of the nuclear option. + +[Issue 715](https://github.com/w3c/webextensions/issues/715): Feature request: Enhance the tab group api to support the new pinning functionality + + * [simeon] Feature request on tabGroups API to pin groups to the bookmarks. Oliver, can you speak to this capability? + * [oliver] I am not familiar with this. + * [rob] Does Safari support the tabGroups API? + * [timothy] We don't, but we have the feature and are interested in shoehorning the functionality in the API. + * [rob] In Firefox there's also interest in tab groups but we don't have the API yet. + * [oliver] The two requests that would be API level changes is to add a pinned property (Boolean) and tabs.query() include closed tab groups, which I'm not familiar with. + * [timothy] We have closed tab groups as well. + * [simeon] Would it make sense to have closed groups be a distinct type of tab to query? + * [timothy] Not necessarily. + * [rob] How does this functionality relate to `sessions.restore`? Based on the description it sounds similar. (pause) Seems no one is familiar offhand. + * [oliver] Pinned fields sounds non-controversial, querying/managing closed groups sounds like something needing more discussion. + +[Issue 716](https://github.com/w3c/webextensions/issues/716): Inconsistent support for [context]menus.getTargetElement() + + * [rob] Feature request for the ability to retrieve the element that is clicked when a context menu was opened. Firefox solved this by introducing `getTargetElement()`. When `contextMenus.onClicked` fires you can get a reference (`targetElementId`) that you pass to the `menus.getTargetElement` function in a content script to retrieve the element. There are workarounds such as exposing the coordinates in the document, but they're lossy. Firefox's approach is a reliable solution. + * [timothy] Against coordinate suggestion as well; interested in implementing Firefox's getTargetElement API. + * [oliver] Treating this as opaque is fine, but I'm curious what this ID looks like in Firefox. + * [rob] It's a generated number in Firefox. I believe it's the timestamp. On click, a weak ref to the element is stored, timestamp is captured and passed to the extension. + * [oliver] Thanks, just wanted to understand the general shape. + * [timothy] I'd want it to be opaque. UUID or some string. + * [rob] It's currently an integer. This enables extensions to pass the value to `getTargetElement` in a code string (`tabs.executeScript`) without serialization concerns. That concern is lesser in MV3 because `scripting.executeScript` does not accept code strings, and accepts `args` for `func` instead. + * [timothy] Want it to be opaque so there's no meaning associated with it. Allows us to modify the implementation later if necessary. E.g. across processes, etc. + * [rob] I don't think that it should be a string; the integer can be a random number, as it is only used to avoid race conditions where “the last clicked element” changed between the time of the invocation of the context menu and the invocation of the script. + * [tomislav] I don't think Timothy means a value you can't look into, just a value without meaning. + * [timothy] Exactly. Not a timestamp. No inherent meaning to the value. + * [rob] Thanks for the clarification - I thought that you meant a string or object by “opaque”. An integer sounds good to me. + * [rob] Safari seems on board. Does Chrome have any oppositions? + * [oliver] I can follow up. + +[Issue 717](https://github.com/w3c/webextensions/issues/717): Request: [ContextMenus] Include ``s in the "page" ContextType (or it's own ContextType) + + * [simeon] The only way to match `` elements is to specify “all”. The request is to offer a specific `contextType` to match ``. + * [tomislav] I'm supportive of a canvas context type. No implementation concerns come to mind. + * [timothy] Commented on the issue, but I'm also supportive of a canvas type. + * [rob] What useful information would an extension get for a canvas? There is no URL or other relevant context. + * [timothy] I think this is related to the previous issue where you need to be able to work with the element to meaningfully interact with it. They lean on each other. + * [simeon] Sounds like we're aligned? + * [rob] I'd like to see more details on use cases. One of the comments was to support a CSS selector to match context menus by selector. That would be a more general way to support this capability. I'm generally in favor of CSS selector. I'm opposed to adding “canvas” ContextType when there is no special context associated with it. + * [timothy] We'd still have the issue of needing getTargetElement to meaningfully interact with the element + * [simeon] Agreed, I think we're discussing which solution to [issue 716](https://github.com/w3c/webextensions/issues/716) is the right approach. + * [timothy] I'm in favor of “canvas” context type because it is simpler than matching by CSS selector. Not worried about API bloat if this case later becomes addressable with selector matching. + * [oliver] I can follow up here. + +[Issue 719](https://github.com/w3c/webextensions/issues/719): Adding a temporary listener just for the current run of the service worker or event page so it doesn't wake up next time for this event + + * [simeon] I believe this is a Chromium issue. If you register an event listener in the background, it will cause the background to wake in response to the event. This doesn't apply to Firefox – a short period after background page startup new event listener registrations won't cause the background to wake. + * [timothy] When the Service worker is finished initializing, we won't register events. + * [rob] The capability request is to address the opposite use case of [issue 501](https://github.com/w3c/webextensions/issues/501) (Proposal: Toggleable event listeners). I think it would be generally useful to allow extensions to explicitly signal that event listeners should not cause the background to start. + * [timothy] Supportive of an explicit signal. We currently have heuristics, can be fragile. + * [oliver] I'd want to follow up on this. + +[Issue 527](https://github.com/w3c/webextensions/issues/527): chrome.scripting.executeScript doesn't resolve/reject for frozen state tabs + + * [oliver] Don't' have time to discuss the larger issue, but Chrome has the concept of a frozen tab state. In the future we're going to freeze more tabs when in power saver mode. We're looking to expose a “frozen” flag on tabs to give extensions a signal that a tab cannot be interacted with. + * [rob] Is it feasible to just throw an error so extensions can try/catch to detect inability to interact? + * [oliver] Not something we've discussed. Can imagine that approach being feasible. Having a flag allows you to not send in the first place. Also applies to the sendMessage API. + * [rob] Defaulting to throwing/rejecting with an option to queue sounds more reasonable than the API call being stuck “forever”. + * [timothy] Having dejavu with bfcache discussions. + * [oliver] Next steps: I can see if we're open to the throwing approach. Any other feedback? + * [timothy] In favor of that. We have a similar concept of frozen/hybernated. + * [rob] Is frozen different from discarded? + * [oliver] In Chrome discarded is completely thrown away, whereas frozen the context is still around but not actively executing. + * [timothy] We have both “thrown away and it will reload when you go to that tab” and “process is suspended until the user focuses it again”. + * [rob] No objections to frozen flag since the feature is applicable in more than one browser. + +The next meeting will be on [Thursday, November 21st, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=673e7800,384). diff --git a/_minutes/README.md b/_minutes/README.md index 95c43776..445fc4d8 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,11 +10,13 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2024-10-24 at 8 AM PDT = https://everytimezone.com/?t=67198e00,384 -- 2024-11-07 at 8 AM PST = https://everytimezone.com/?t=672c0300,3c0 +- 2024-11-21 at 8 AM PST = https://everytimezone.com/?t=673e7800,384 +- 2024-12-05 at 8 AM PST = https://everytimezone.com/?t=6750ed00,384 ## Past meetings +* 2024-11-07 ([minutes](2024-11-07-wecg.md)) +* 2024-10-24 ([minutes](2024-10-24-wecg.md)) * 2024-10-10 ([minutes](2024-10-10-wecg.md)) * 2024-09-27 at TPAC ([minutes](2024-09-27-wecg-tpac.md)) * 2024-09-26 at TPAC ([minutes](2024-09-26-wecg-tpac.md)) @@ -23,14 +25,14 @@ After the end of each meeting, meeting notes are published here. * 2024-09-23 at TPAC ([minutes](2024-09-23-wecg-tpac.md)) * 2024-09-12 ([minutes](2024-09-12-wecg.md)) * 2024-08-29 ([minutes](2024-08-29-wecg.md)) -* 2024-08-15 ([minutes](2024-08-15-wecg.md)) -* 2024-08-01 ([minutes](2024-08-01-wecg.md))
All past meeting notes **2024** +* 2024-11-07 ([minutes](2024-11-07-wecg.md)) +* 2024-10-24 ([minutes](2024-10-24-wecg.md)) * 2024-10-10 ([minutes](2024-10-10-wecg.md)) * 2024-09-27 at TPAC ([minutes](2024-09-27-wecg-tpac.md)) * 2024-09-26 at TPAC ([minutes](2024-09-26-wecg-tpac.md))