From 0e4555d6bc9f4af3c7f121c6c3ca1f9f4d270126 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Thu, 16 Jan 2025 23:45:12 +0100 Subject: [PATCH] Publish minutes of 2025-01-16 meeting --- _minutes/2025-01-16-wecg.md | 126 ++++++++++++++++++++++++++++++++++++ _minutes/README.md | 8 ++- 2 files changed, 132 insertions(+), 2 deletions(-) create mode 100644 _minutes/2025-01-16-wecg.md diff --git a/_minutes/2025-01-16-wecg.md b/_minutes/2025-01-16-wecg.md new file mode 100644 index 00000000..aa99757f --- /dev/null +++ b/_minutes/2025-01-16-wecg.md @@ -0,0 +1,126 @@ +# WECG Meetings 2025, Public Notes, Jan 16 + + * Chair: Simeon Vincent + * Scribes: Rob Wu + +Time: 8 AM PST = https://everytimezone.com/?t=67884c00,384 +Call-in details: [WebExtensions CG, 16th January 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250116T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #743](https://github.com/w3c/webextensions/issues/743), [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** (25 minutes) + * [Issue 744](https://github.com/w3c/webextensions/issues/744): Proposal: A DNR rule type to intercept top-document navigation ([@gorhill](https://github.com/gorhill)) + * [Issue 746](https://github.com/w3c/webextensions/issues/746): Proposal: Persistent Authentication ([@erosman](https://github.com/erosman)) + * [Issue 747](https://github.com/w3c/webextensions/issues/747): API to invalidate BFCache'd webpage with outdated content added by the extension ([@tophf](https://github.com/tophf)) + * [Issue 748](https://github.com/w3c/webextensions/issues/748): Proposal: Support Extended "browser_specific_settings" ([@erosman](https://github.com/erosman)) + * **Timely issues** (0 minutes) + * **Check-in on existing issues** (20 minutes) + * [Issue 19](https://github.com/w3c/webextensions/issues/19): request: APIs and infrastructure to simplify cross-browser automated testing of extensions ([@chrmod](https://github.com/chrmod)) + * [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) ([@hackademix](https://github.com/hackademix)) + * [Issue 749](https://github.com/w3c/webextensions/issues/749): Proposal: Support a shared state for tab groups + + +## Attendees (sign yourself in) + + 1. Rob Wu (Mozilla) + 2. Tomislav Jovanovic (Mozilla) + 3. Simeon Vincent (Mozilla) + 4. Giorgio Maone (NoScript, Tor) + 5. Oliver Dunk (Google) + 6. Patrick Kettner (Google) + 7. Krzysztof Modras (Ghostery) + 8. Mukul Purohit (Microsoft) + 9. David Johnson (Apple) + 10. Timothy Hatcher (Apple) + 11. Carlos Jeurissen (Jeurissen Apps) + 12. Casey Garland (Capital One) + 13. Aaron Selya (Google) + + +## Meeting notes + +[Issue 744](https://github.com/w3c/webextensions/issues/744): Proposal: A DNR rule type to intercept top-document navigation + + * [simeon] Issue filed by gorhill. He is not in this meeting right now. + * [krzysztof] Overlaps with use case of Ghostery. When navigating, would like to intercept and show a different page, to allow users to make a choice between continuing. In MV3, is able to block a load, but without a way to show which extension is responsible for it. + * [oliver] What information would you need from the original request? + * [krzysztof] Need the URL. Others have mentioned POST data. Can use non-blocking web request to work around that, but requires additional work. + * [rob] Beyond current limits, could see the need to provide a method to replicate the original request. + * [timothy] Browser vendors could implement with browser UI. Main concern is sub-resource navigation when the user finally confirms. There may be other rules that need to be disabled, could be hard to do without extension intercession. + * [krzysztof] Interception happens for a reason. Navigation can be blocked or not, but … + * [timothy] If uBlock had a way to disable clicking through to a navigation, there may be other rules that are necessary. For example, subresource loading on the destination may be blocked when the “proceed” action would normally allow it. + * [krzysztof] We know from users that common use cases include allowing navigation from a certain interaction on. For example, allow Google from this navigation for the rest of the tab session. There are options we'd like to offer users. + * [rob] When I read this request and try to generalize, extensions may want to intercept and do something with the original request. Navigation confirmation, but also cases like mimetype handlers. For that use case, the desired direction would be to redirect to an extension page, then offer an API to do something from that page. From a user perspective, might also be nice to show the original URL that they intended to visit. Can still show that the extension is interceding through other UI treatment. + * [timothy] This is what error pages do - they show the original URL. + * [krzysztof] Having branding here is useful because it's one of the few cases where we are showing content to users. Useful for content blockers as well as other types of content. + * [rob] Could you come up with an API proposal and description? Current suggestion in the issue fits within existing DNR APIs, but if we weren't limiting ourselves to the current APIs, what might that look like? + * [krzysztof] Will need to give this a closer look. Will comment on the issue. + +[Issue 746](https://github.com/w3c/webextensions/issues/746): Proposal: Persistent Authentication + + * [simeon] Request for way to declare response to onAuthRequired, to avoid the need to wait for extension background startup. + * [tomislav] An extension can already respond asynchronously from onAuthRequired if desired. + * [simeon] Is this issue addressed by that capability, or is there another issue? + * [rob] This issue is about trying to minimize the delay. For this specific report, given the other issues filed by this user, this may be proxy-specific use case. In which case, an enhancement to the proxy API may be more appropriate. Perhaps I should point to Chrome's capabilities (which already offers a declarative proxy API) and ask whether this is also desirable in Firefox. + * [patrick] Does indeed seem like they're reporting an issue specific to Firefox. + * [tomislav] I'll start by asking for more information to clarify if it's a feature request or Firefox bug. + +[Issue 747](https://github.com/w3c/webextensions/issues/747): API to invalidate BFCache'd webpage with outdated content added by the extension + + * [simeon] (describes issue) + * [oliver] Preferred approach is to use event and when the page is restored, do something from there. We're trying to move away from mechanisms to intentionally evict items from the bfcache. + * [rob] “pageshow” event exists and is fired when the page is restored. This was also mentioned in the issue, but that this gives a poor experience due to the latency in querying the state from the extension. A way to address it might be to offer an object that can be modified to the extension that would be propagated to processes and make it synchronously available through APIs. That should minimize the amount of delays. E.g. `browser.runtime.getGlobalValue(“key”)`. Discussed before as globalParams. + * [timothy] Sounds like better approach to me. Don't want to expose an API to let extensions evict pages – too heavy a hammer. Any delay we introduce through custom extension APIs would be lower total cost than a complete reload. + * [oliver] Could potentially allow N milliseconds or code to execute before the page runs in order to prepare the page. + * [rob] What's the next step? Are we all opposed to this specific feature request? + * [timothy] I'm concerned about introducing a method to allow bfcache eviction, because this could too easily be used to inadvertently degrade the user experience. + * [simeon] Should we close this out? Convert it to a discussion? + * [oliver] Would have liked an issue tracking global data, but previous discussion ([issue 536](https://github.com/w3c/webextensions/issues/536)) was focused on properties exposed on the scripting API. + * Chrome proposal for global params: https://github.com/w3c/webextensions/issues/536#issuecomment-2200692043 + * [tomislav] Would there be a concern if the global params mechanism may return the same or different values at different times? + * [rob] For that reason, I'd suggest a method and document that it would return the latest value, which may be the same or a different value compared to before. + * Resolution: put “opposed” label from every browser, and ask issue author whether the proposals above would address their use case. + +[Issue 748](https://github.com/w3c/webextensions/issues/748): Proposal: Support Extended "browser_specific_settings" + + * [rob] Two issues in one. Strict min version support across browsers in the browser_specific_settings object. Chrome previously was not opposed, but didn't have time. Second, “background” in browser specific settings to override the top level background key. Chrome and Firefox were opposed. Not sure about Apple. + * [david] Opposed. + * [krzysztof] Trying to add context for the extension dev, currently extensions have to maintain multiple manifest files and some kind of build system. The intent of this request is to lower the burden to maintain across browsers. + * [rob] For things that are hard-incompatible, this is clearly not ideal. We are moving towards not hard erroring where possible so that extension developers can use the same manifest file across browsers. + * [patrick] Main call out is SVG icons. Obviously they can't be used in browsers that don't support SVGs. As a result, you have to have multiple or generated manifest files. + * [oliver] The icon_variants proposal would solve that specific issue. + * [krzysztof] This is also useful for futureproofing/backwards compatibility. May want to opt into a feature that's available in later versions of a browser. For example, Safari's handling of background pages changed over time, and we had to tailor our manifest for specific versions of Safari. + * [timothy] Tricky. Defers a lot of logic to the browser. + * [krzysztof] Know it's hard, but this is a common problem in the community. + * [carlos] On Android, you can say specific XML files should be used starting with version x. That type of version support may allow for tailoring things + * [patrick] I think this version may be best if split into two separate issues. + * [rob] strict_min_version is already tracked by [issue 115](https://github.com/w3c/webextensions/issues/115). + * [patrick] Then the question is whether the value of this request outweighs the cost. + * [timothy] If we do implement it, there will be some minimum version that won't understand the field. So, do we agree to have a common version that we all parse without errors, or do we all work to support this proposal & spend 6-12 months on this. My preference is to avoid unnecessary makework. + * [patrick] Agreed with the goal. A single manifest is a nice-to-have; the group agreed to use warnings for keys it did not understand. + * [rob] Example of why we would not want generic support for overriding all manifest keys: if there is a difference between effective permissions, what should be shown in the permission prompt? What should happen when the browser updates to a version where the manifest behavior differs? Simplest way to use strict_min_version so that existing users on older browsers can keep the older version of the extension. + * [carlos] Extension stores could offer deploying multiple packages to support different/older browser versions. + * [rob] In Firefox, the extension store can offer older versions of an extension to users on older browsers. + * [krzysztof] If we don't have this, it's very difficult for extensions to support old versions of browsers. + * [tomislav] Non-current versions of browsers are unsupported. + * [krzysztof] Not every user can stay on the latest version, e.g. because they cannot afford new hardware. + * [simeon] In the interest of time, let's move on to the next issue. + +[Issue 19](https://github.com/w3c/webextensions/issues/19): request: APIs and infrastructure to simplify cross-browser automated testing of extensions + + * (see krzysztof's comment at https://github.com/w3c/webextensions/issues/19#issuecomment-2590291221) + * [krzysztof] Thanks to everyone who helped push this forward and WebDrive-bidi, it is now possible to install extensions through webdriver. It was previously not a first-class supported feature of browsers to install extensions, which hinders the ability to test extensions. Installing/uninstalling extensions is now part of webdriver-bidi. Next we'll likely want to tackle browser interaction such as opening the popup, showing the sidebar, etc. Need feedback on what to prioritize next. + * [tomsilav] Thanks for working on this. Krzystof has created Firefox patches, I'm going to work to support landing those changes. + +[Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) + + * Skipped due to lack of time. + +The next meeting will be on [Thursday, January 30th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=679ac100,384). diff --git a/_minutes/README.md b/_minutes/README.md index 3aa5f9b5..a89f62c6 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,21 +10,25 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2025-01-16 at 8 AM PST = https://everytimezone.com/?t=67884c00,384 - 2025-01-30 at 8 AM PST = https://everytimezone.com/?t=679ac100,384 +- 2025-02-13 at 8 AM PST = https://everytimezone.com/?t=67ad3600,384 ## Past meetings +* 2025-01-16 ([minutes](2025-01-16-wecg.md)) * 2024-12-19 ([minutes](2024-12-19-wecg.md)) * 2024-12-05 ([minutes](2024-12-05-wecg.md)) * 2024-11-21 ([minutes](2024-11-21-wecg.md)) * 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))
All past meeting notes +**2025** + +* 2025-01-16 ([minutes](2025-01-16-wecg.md)) + **2024** * 2024-12-19 ([minutes](2024-12-19-wecg.md))