Merge branch 'w3c:main' into getPartitionKey_update

_minutes/2024-09-26-wecg.md

@@ -0,0 +1,175 @@
+# WECG Meetings 2024, Public Notes, Sep 26
+
+ * Chair: Simeon Vincent
+ * Scribes: Rob Wu
+
+Time: 8 AM PDT = https://everytimezone.com/?t=66f4a400,384
+Call-in details: [WebExtensions CG, 26th September 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240926T080000/)
+Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)
+
+
+## Agenda: [discussion in #686](https://github.com/w3c/webextensions/issues/686), [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)
+   * TPAC is in full swing!
+ * **Triage** (25 minutes)
+   * [Issue 695](https://github.com/w3c/webextensions/issues/695): documentUrl and documentOrigin should be just url and origin in runtime.getContexts and be defined for the worker context
+   * [Issue 694](https://github.com/w3c/webextensions/issues/694):  [DNR] in contrast to webRequestBlocking, declarativeNetRequest rules are not applied if the request is redirected #694
+   * [Issue 693](https://github.com/w3c/webextensions/issues/693): Add API to switch focus from sidePanel to main document to enable accessibility features
+   * [Issue 692](https://github.com/w3c/webextensions/issues/692): Addressing auto-sizing of extension UI (options, popup, sidepanel)
+   * [Issue 687](https://github.com/w3c/webextensions/issues/687): Proposal: Targeted Permissions
+   * [PR 690](https://github.com/w3c/webextensions/pull/690): Proposal: add cookies.removeAll() method
+   * [PR 691](https://github.com/w3c/webextensions/pull/691): Multiple User Script Worlds proposal polish
+ * **Timely issues** (30 minutes)
+   * TPAC Recap (so far) ([wiki](https://github.com/w3c/webextensions/wiki/TPAC-2024-Coordination))
+ * **Check-in on existing issues** (0 minutes)
+   * N/A
+
+
+## Attendees (sign yourself in)
+
+ 1. Simeon Vincent (Mozilla)
+ 2. Oliver Dunk (Google)
+ 3. David Johnson (Apple)
+ 4. Timothy Hatcher (Apple)
+ 5. Elijah Sawyers (Apple)
+ 6. Kiara Rose (Apple)
+ 7. Rob Wu (Mozilla)
+ 8. Mukul Purohit (Microsoft)
+ 9. Carlos Jeurissen (Jeurissen Apps)
+ 10. Mike Selander (1Password)
+ 11. George Henderson (Capital One)
+ 12. Tim Heflin (Keeper)
+
+
+## Meeting notes
+
+Intro
+
+ * [simeon] Today is a different session than usual; we'll do an issue triage like usual and then check in with what has happened at TPAC so far.
+
+[Issue 695](https://github.com/w3c/webextensions/issues/695): documentUrl and documentOrigin should be just url and origin in runtime.getContexts and be defined for the worker context
+
+ * [simeon] toph argues that the “document” prefix is redundant, and that it should be dropped.
+ * [timothy] I'm usually in favor of not being redundant in APIs.
+ * [oliver] In principle that seems to make sense. Not sure what we'd do in chrome. Wouldn't like to have both.
+ * [simeon] Suggestion was to alias to the new names.
+ * [rob] Currently only extension contexts are returned. During design, we also accounted for content scripts. In that case url would be ambiguous and documentUrl would be clear. SWs don't have a meaningful URL save for the entry point. Don't see much value in this change.
+ * [timothy] Has Firefox shipped getContexts?
+ * [rob] Yes, Firefox has shipped getContexts() already.
+ * [simeon] Also leaning towards opposed.
+ * [timothy] Mostly leaning towards neutral since we haven't implemented it.
+ * [oliver] Are we aligned with closing it?
+ * [rob] Yes.
+ * **Resolution**: Close, consider changing in next manifest version if any.
+
+[Issue 694](https://github.com/w3c/webextensions/issues/694): [DNR] in contrast to webRequestBlocking, declarativeNetRequest rules are not applied if the request is redirected
+
+ * [simeon] I think we discussed this yesterday. Rob, do you recall the next steps?
+ * [rob] I think Chrome was going to double check the intended behavior.
+ * [oliver] Yeah, we think this might be the intended behavior and webRequest was “wrong”. Will double check
+ * [rob] Wondering about XHR/fetch. Do redirects preserve headers?
+ * [simeon] Not sure. I think so but wouldn't bet on it.
+ * [rob] Preserving the header after a cross-origin redirect could result in inadvertent leakage of headers. Would especially be a problem for things like Authorization headers with sensitive auth tokens, injected through declarativeNetRequest.updateSessionRules.
+ * **Resolution**: Next steps are to test XHR, Chrome to double-check their intended behavior, and for someone to test cross-browser behavior.
+
+[Issue 693](https://github.com/w3c/webextensions/issues/693): Add API to switch focus from sidePanel to main document to enable accessibility features
+
+ * [simeon] We discussed this during the in-person meeting earlier this week; Oliver summarized the outcome at https://github.com/w3c/webextensions/issues/693#issuecomment-2372499691
+ * [oliver] The behavior[ @hanguokai](https://github.com/hanguokai) mentioned seems like a bug. We should look at ensuring the side panel takes focus from the page when it is first opened regardless of the mechanism used to open it.
+ * [oliver] We are supportive of implementing a tabs.focus() method which would return focus to the web content. This would close the popup if open and move focus away from other parts of the UI such as the address bar.
+ * [simeon] We are all supportive of this, as reflected in the label.
+
+[Issue 692](https://github.com/w3c/webextensions/issues/692): Addressing auto-sizing of extension UI (options, popup, sidepanel)
+
+ * [carlos] Historically the viewport of a viewport is not designed by the web page, but the browser. Extensions are allowed to define the viewport in some cases (options_ui, popup, sidepanel). As an extension developer it is difficult to work with the browser and extension controlling the dimensions.
+ * [timothy] The scenario Carlos is referring to is when a page is used in a tab, in a popup, etc. A potential solution would be to support a media query to control styles dependent on auto-sizing. I think that it would be useful.
+ * [oliver] Don't recall if Chrome's options UI has autosize behavior.
+ * [rob] Yes it does, and sometimes it runs off the screen.
+ * [oliver] To confirm, the auto-size media query doesn't exist today.
+ * [carlos] Correct, this would be a new capability to handle this and similar cases.
+ * [timothy] Options page is strange too - in Chrome it is embedded in a subview, in Safari it is a tab.
+ * [carlos] And sometimes only one of the width/height can be controlled by the extension.
+ * [carlos] (...) autosize side bar.
+ * [timothy] Not sure about that.
+ * [oliver] I don't think that we would want autosize of sidepanels in Chrome.
+ * [simeon] When I discussed this with Devlin, he expressed the desire that this be solved at the web platform level rather than just extensions.
+ * [rob] Now that you mention it, I recall discussing something like this before
+ * [carlos] I believe we verbally discussed it ~2 years ago. Setting a fixed height can result in auto-size leading to two scrollbars.
+ * [rob] How do you address this today?
+ * [carlos] A bunch of hacks. Too obtuse to expect other developers to implement. E.g. 600x600, and if the viewport is below 600 and the width is above, then apply the full size. But if that is done before the page is fully loaded, the popup will be super small. Sometimes the scrollbar adds something to the width/height.
+ * [rob] Recently saw a Firefox bug report that turned out to be a bug by the extension not accounting for zoom level. How would you account for that here? Would be nice to have zoom behavior specified more clearly.
+ * [simeon] Sounds like we are all supportive.
+ * [rob] Supportive here means open to improvements. There is no concrete suggestion here.
+ * [rob] Emilio (from Mozilla) commented on the issue. He is also here in person during TPAC this week. Are there Google folks working on layout/CSS and also here? Perhaps we can set up a meeting to discuss this topic.
+ * [oliver] Rachel Andrew from the CSS Working Group is at TPAC. I'll see if we can set something up or I can at least get some thoughts.
+ * **Resolution**: Open to further discussion. Current path we want to explore is working with CSS WG on an auto-size media query.
+
+[Issue 687](https://github.com/w3c/webextensions/issues/687): Proposal: Targeted Permissions
+
+ * [simeon] Targeted Permissions request is aimed at narrowing the permissions that the extensions have to request so that they don't have to request access to powerful permissions to access only a part of an API namespace. E.g. general capabilities in the history API is to delete entries, whereas entries with privacy controls are getVisits().
+ * [rob] History may not be a great example. Users would likely be surprised and disappointed if the extension deletes their full history.
+ * [oliver] General idea sounds useful, we'd be neutral on this.
+ * [] On a case-by-case basis.
+ * [rob] We use namespaces to group functionality, but also true that several capabilities exposed on namespaces are not unsafe. For example, download.download. It's possible to trigger a download on the web by creating a download anchor and triggering a click on it. See that we could expose more functionality without having to request dangerous permission. Another example is webNavigation. Would be nice to observe navigations that you have permissions to without having to request a new permission-with-warning.
+ * [timothy] And also getFrames().
+ * [rob] Hmm, perhaps for webNavigation we should just drop the warning.
+ * [simeon] I have wanted to use webNavigation many times in the past and have avoided it because of the permission warning.
+ * [rob] Same.
+ * [carlos] Same.
+ * [timothy] Are we aligned on dropping webNavigation warning?
+ * [simeon] We have a session on permissions later today, perhaps we can cover it there too.
+ * [timothy] Let's table for later today.
+ * [rob] Note that TPAC meeting notes will be published later.
+ * **Resolution**: Will be discussed more at a dedicated session later today at TPAC.
+
+[PR 690](https://github.com/w3c/webextensions/pull/690): Proposal: add cookies.removeAll() method
+
+ * [simeon] Aaron from Google opened a proposal to add cookies.removeAll(). I don't have a lot of context, do you Rob?
+ * [rob] Ran into Aaron yesterday and discussed the context for the request. He was working on a unit test in the context of cookie partitioning (CHIPS) and noticed that remove() removed more cookies than expected, and fixed that. He saw utility in removing multiple matching cookies at once and opened a bug report.
+ * [rob] I noted that this is not unique to CHIPS. I reported a bug a couple years ago that remove() removed more than expected in Chrome.
+   * https://issues.chromium.org/issues/40572551
+ * [rob] The API is supposed to return a descriptor of the matched cookie by design (as indicated by its return value), but in reality Chrome may remove more than one cookie. Partition key isn't the only way to match multiple cookies. A cookie's “primary key” is composed of multiple properties, but the cookies.remove() API does not accept enough properties to precisely match one cookie.
+ * [timothy] What cookie should be removed when the parameters to cookie.remove() match multiple cookies?
+ * [rob] Unspecified. In Firefox we iterate over matching cookies and remove the first match. In Chrome it removed all matching cookies, but Aaron changed this to match fewer cookies when partitioning is involved.
+ * [timothy] I don't know what we would do.
+ * [rob] Would be useful to specify the behavior more clearly to aid in interoperability. Aaron was working on this primarily due to cookie partitioning, not clear if he would work on improvements here. Oliver, thoughts on how to handle this?
+ * [oliver] Only concern is that it could be a breaking change. “Best match” sounds best.
+ * [timothy] Right, like Rob said we don't have info to make a better match.
+ * [rob] I analyzed this 7 years ago, and removing one would be compatible (and usually  expected) by extensions. See “4. Analysis of API usage by extensions in the wild.” at https://bugzilla.mozilla.org/show_bug.cgi?id=1387957#c9
+ * [oliver] Open discussion on the proposal cookies.removeAll() with an empty object, would the default behavior be to delete everything? I suggested we require a url property.
+ * [timothy] I'm in favor of requiring at least some filter. For example, removing a tracker cookie with a known name across all domains.
+ * [oliver] Yes, makes sense.
+ * [rob] Agreed.
+ * [simeon]  If you want to remove all, would you provide a url with a broad host permission pattern?
+ * [oliver] You can already use the browsingData API.
+ * [mukul] The proposal is to have a separate API, we can consider new options.
+   * `cookies.remove(filter, <criteria= firstMatch|allMatch>)`
+ * [oliver] A potential issue is return type.
+ * [rob]  Wouldn't make it an option. Can already be confusing. Matches the pattern of get & getAll. remove and removeAll would be symmetrical.
+ * [oliver] Does the proposal not mention the return type?
+ * [rob] That is feedback that I already put there.
+ * [oliver] My expectation is an array of removed cookies.
+ * [rob] Wonder if we should not return deleted cookies as it would be more optimal from the DB perspective. If they wanted the cookies, they could do getAll first. But that would require both methods to have the same semantics. We can have some specific exceptions, such as not accepting an empty object as discussed before. getAll has some special handling for partitionKey that primarily serves backwards-compatibility purposes, but is odd from the API design perspective. Since removeAll() is new, we could consider different behavior for partitionKey: getAll() currently matches unpartitioned cookies only when partitionKey, removeAll could match all cookies (including partitioned cookies) if partitionKey is omitted.
+ * [oliver] In Chrome the data that is easily available is the number of deleted cookies.
+ * [timothy] In Safari, we would likely have to do a get before a remove. We can easily  return the results without extra work.
+ * [rob] In Firefox we also query before removing.
+ * [rob] Let's revisit this issue in the future once Aaron has updated the PR.
+
+[PR 691](https://github.com/w3c/webextensions/pull/691): Multiple User Script Worlds proposal polish
+
+ * [simeon] Small PR that I created; small polish to clarify text in the proposal. I also realize that I don't understand the term “function signature”.
+
+Closing words
+
+ * [simeon] We planned to talk about TPAC, but we have spent all time discussing issues. We will discuss the outcomes of this week later.
+ * [rob] And link the meeting notes from https://github.com/w3c/webextensions/issues/659.
+ * [oliver] For people interested in joining TPAC, where could they join now?
+ * [simeon] Wiki page with up-to-date schedule: https://github.com/w3c/webextensions/wiki/TPAC-2024-Coordination
+ * [simeon] The work-in-progress notes are linked from the Agenda section of the TPAC 2024 coordination page. We'll get the notes polished and publish after TPAC.
+
+The next meeting will be on [Thursday, October 10th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=67071900,384)