-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #643 from w3c/meeting-2024-06-20
Publish minutes of 2024-06-20 meeting
- Loading branch information
Showing
2 changed files
with
164 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,161 @@ | ||
| # WECG Meetings 2024, Public Notes, Jun 20 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=66737100,384 | ||
| Call-in details: [WebExtensions CG, 20th June 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240620T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #635](https://github.com/w3c/webextensions/issues/635), [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 637](https://github.com/w3c/webextensions/issues/637): Allow to create sandboxed iframes in background script of addons | ||
| * [Issue 638](https://github.com/w3c/webextensions/issues/638): Proposal: declarativeNetRequest: Add a way to feature detect whether a specific RuleConditon is supported on the current browser | ||
| * [Issue 639](https://github.com/w3c/webextensions/issues/639): i18n.getMessage() pluralization | ||
| * [Issue 640](https://github.com/w3c/webextensions/issues/640): Proposal: Remove multiple bookmarks in bookmarks.remove() | ||
| * [Issue 642](https://github.com/w3c/webextensions/issues/642): Align on properly formed language tags | ||
| * **Timely issues** (10 minutes) | ||
| * [Issue 636](https://github.com/w3c/webextensions/issues/636): Proposal: Decode regexFilter matches in Declarative Net Request as query parameters | ||
| * [Issue 460](https://github.com/w3c/webextensions/issues/460#issuecomment-2169017147): Proposal: declarativeNetRequest: matching based on response headers | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [PR 641](https://github.com/w3c/webextensions/pull/641): Proposal: Per-extension language preferences | ||
| * **In-meeting topics** | ||
| * Automated extension API testing | ||
| * TPAC 2024 | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Oliver Dunk (Google) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Giorgio Maone (Tor, NoScript) | ||
| 4. Timothy Hatcher (Apple) | ||
| 5. Solomon Kinard (Google) | ||
| 6. Simeon Vincent (Mozilla) | ||
| 7. Jackie Han (no affiliation) | ||
| 8. Tomislav Jovanovic (Mozilla) | ||
| 9. Maxim Topciu (AdGuard) | ||
| 10. Mukul Purohit (Microsoft) | ||
| 11. Rémi Pujo (Dashlane) | ||
| 12. Carlos Jeurissen (Jeurissen Apps) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 637](https://github.com/w3c/webextensions/issues/637): Allow to create sandboxed iframes in background script of addons | ||
|
|
||
| * [timothy] Relevant to Firefox and Safari because Chrome requires service workers. | ||
| * [rob] In Chrome the solution is to use an offscreen document plus the manifest sandbox key. | ||
| * [oliver] Offscreen document should not be seen as the long-term solution. But at the same time it offers a way to do so, so not a priority to develop an alternative API. Current focus is on providing APIs to help with migrating to Manifest Version 3. | ||
| * [rob] manifest sandbox is currently supported in Chrome only. Is Safari going to support it? | ||
| * [timothy] On our timeline, but don't know when it will be supported. | ||
| * [tomislav] Firefox does support the regular CSP sandbox. | ||
| * [rob] sandbox on the web platform is inherit and can only be stricter; The manifest sandbox key enables extensions to specify documents that have a looser CSP, without access to extension APIs. | ||
| * [simeon] Chrome supports the manifest sandbox key to enable extensions to define a page that executes on a null origin. Sandboxed pages don't have access to extension APIs. For Chrome's MV3 transition efforts, this was a notable capability because the MV3 CSP restrictions prevented extensions from executing arbitrary code. | ||
| * [simeon] Any concerns against implementing manifest sandbox? | ||
| * [tomislav] No real concerns. | ||
| * [timothy] No objections. | ||
| * [rob] Might make sense to have sandboxed pages isolated to a specific subdirectory. | ||
| * [oliver] Since you have to declare the sandboxed page in the manifest, what benefit does a specific directory provide? | ||
| * [rob] Page wouldn't be able to include resources outside the directory. Reduces tracing work required to figure out exactly what code is executed. | ||
|
|
||
| [Issue 638](https://github.com/w3c/webextensions/issues/638): Proposal: declarativeNetRequest: Add a way to feature detect whether a specific RuleConditon is supported on the current browser | ||
|
|
||
| * [timothy] Essentially checking whether a condition is supported and would work. Rob suggested updateSessionRules and catch the error. | ||
| * [rob] The usual implementation in Chrome is to throw when an API receives an unexpected property or value, I guess that this may be an implementation detail where the flag that controls its availability is checked later. So the API recognizes the input, but the rule engine ignores it. | ||
| * [timothy] I see value in verifying whether a specific rule can be used. | ||
| * [oliver] [Issue 449](https://github.com/w3c/webextensions/issues/449) is about introducing a isRuleSupported() . | ||
| * [timothy] In Safari we return the original value. | ||
| * [rob] In Firefox the processed value is returned. I recall that Chrome stores the JSON separately from the compiled rules, so perhaps it returns the original value. | ||
| * [oliver] When we add a dynamic rule with an unrecognized value, we do throw. | ||
| * [timothy] Suggest closing this one in favor of [issue 449](https://github.com/w3c/webextensions/issues/449). | ||
|
|
||
| [Issue 639](https://github.com/w3c/webextensions/issues/639): i18n.getMessage() pluralization | ||
|
|
||
| * [timothy] This is more common these days; handling numbers/localization in different locales. | ||
| * [tomislav] The linked spec (https://github.com/tc39/proposal-intl-messageformat) is part of the Message Format 2 format, which is also worked on by Mozillians. Instead of bolting on more features on the existing JSON format I would be in favor of moving towards MF2. | ||
| * [timothy] I tend to agree. We don't need to reinvent the wheel. | ||
| * [oliver] I recall having discussed this before, but cannot find an issue. | ||
| * [carlos] The topic was suggested for TPAC 2023: https://github.com/w3c/webextensions/issues/385#issuecomment-1644126655 | ||
| * [rob] Briefly discussed before at TPAC 2023: https://github.com/w3c/webextensions/blob/main/_minutes/2023-09-11-2023-09-14-tpac-extra.md?plain=1#L444-L447 | ||
|
|
||
| [Issue 640](https://github.com/w3c/webextensions/issues/640): Proposal: Remove multiple bookmarks in bookmarks.remove() | ||
|
|
||
| * [timothy] We don't support bookmarks API in Safari, but this makes sense. | ||
| * [oliver] I don't see issues; I'll talk with the internal people at Chrome who work on the bookmarks API. | ||
| * [simeon] I'm supportive. Feels like a basic API ergonomics issue to me, and the pattern is well established with other APIs. | ||
|
|
||
| [Issue 642](https://github.com/w3c/webextensions/issues/642): Align on properly formed language tags | ||
|
|
||
| * [carlos] Seems like there is no standard set of supported syntax for language tags in extensions. Suggest standardizing on BCP47. | ||
| * [simeon] Why BCP47? | ||
| * [tomislav] All modern web platform APIs use that. | ||
| * [simeon] tophf raised the concern in [a comment on the issue](https://github.com/w3c/webextensions/issues/642#issuecomment-2179107236) that existing tools use a different standard ([ISO/IEC 15897 standard](https://en.wikipedia.org/wiki/ISO/IEC_15897)). | ||
| * [carlos] That is why I suggest a manifest version bump. | ||
| * [carlos] Firefox already supports both. | ||
| * [timothy] We require underscores, but we can easily change it. I would be supportive of changing it or looking for both. | ||
| * [alexei] I think that this is a place where the browser should be forgiving. Accept the good way and continue supporting the legacy way. | ||
| * [rob] Sounds good to me. | ||
| * [oliver] Carlos, you mentioned that a BCP47 language tag is returned by i18n.getUILanguage. Were you able to test that? | ||
| * [carlos] I did some testing indeed. `i18n.getUILanguage` returns a BCP47 language tag (with hyphens) in both Chrome and Firefox. I believe the same is true for Safari. However in Chrome `i18n.getMessage(‘@@ui_locale')` returns underscores while in Firefox, it returns hyphens. | ||
| * [rob] What does it mean to declare “supportive” on the issue? | ||
| * [carlos] Summarize, support BCP47 in all areas we use language tags in the extension platform. While keeping support for the underscores as suggested by Alexei | ||
| * [rob] I would support that, and not discontinue the previous format for backwards-compatibility. | ||
| * [oliver] I'll follow up internally to check if this is feasible. | ||
|
|
||
| [Issue 636](https://github.com/w3c/webextensions/issues/636): Proposal: Decode regexFilter matches in Declarative Net Request as query parameters | ||
|
|
||
| * [oliver] Alexei shared feedback in a previous issue about wanting to redirect a request to a partial match of a URL. Rob already provided feedback, more feedback is welcome. We've wanted to tackle this for a bit and are considering adding it to our roadmap. | ||
| * [oliver] The use case is to handle when you click a link and are taken to a URL such as [example.com/redirect?url=something](http://example.com/redirect?url=something). Privacy Badger and other similar extensions want to be able to redirect directly to the destination from the query parameter using Declarative Net Request. | ||
| * [alexei] It is a way to clean tracking links. | ||
| * [rob] The issue appears to be very focused on this specific use case. My suggestion in [a comment on the issue](https://github.com/w3c/webextensions/issues/636#issuecomment-2165978322) was to make it a bit broader to be extensible for more use cases. | ||
| * [oliver] No strong feelings, want to balance implementation complexity. | ||
| * [timothy] I like Rob's suggestion, will read further. | ||
|
|
||
| [Issue 460](https://github.com/w3c/webextensions/issues/460#issuecomment-2169017147): Proposal: declarativeNetRequest: matching based on response headers | ||
|
|
||
| * [oliver] Exact match is very limited, we're looking into various ways of matching substrings. Multiple options considered, latest new question is whether to support globs (? and \*) | ||
| * [alexei] uBlock was interested in checking if the numeric value for a content length is over a limit. | ||
| * [oliver] Seems like a nice use case to address. | ||
| * [rob] Possible to create multiple patterns to match that, but it would be quite a hack. | ||
| * [rob] In the issue I proposed a simple substring match to enable the browser to easily/quickly reject a rule before evaluating a more complicated version of the pattern. | ||
| * [oliver] We were hoping that globs would offer the balance between functionality and performance. Would that work in Firefox? | ||
| * [rob] I would have to profile. Internally we transform globs to regular expressions except for very simple cases. | ||
| * [rob] Is there a timeline on settling the design? | ||
| * [oliver] Soon. This is the last major thing to resolve before we release the API. | ||
| * [timothy] I think globs would be okay. We have regexp in other places, so I wouldn't be opposed to that. | ||
|
|
||
| [PR 641](https://github.com/w3c/webextensions/pull/641): Proposal: Per-extension language preferences | ||
|
|
||
| * [timothy] Jackie opened a PR with a proposal for setting the language. | ||
| * [jackie] Feedback is welcome. | ||
|
|
||
| [PR 569](https://github.com/w3c/webextensions/pull/569): Proposal: i18n-system-languages | ||
|
|
||
| * [timothy] What is the status of this PR? | ||
| * [rob] Does not have a sponsoring browser. Our proposal process requires a sponsoring browser before merging proposals. | ||
| * [timothy] I'd be interested in sponsoring this. | ||
| * [carlos] Devlin also mentioned interest in sponsoring this. | ||
| * [oliver] On our side we would not mind sponsoring. | ||
| * [carlos] So Rob, what do you think about it? | ||
| * [rob] I'll take a look and probably sign off. | ||
|
|
||
| End of meeting - random questions | ||
|
|
||
| * Automated extension API testing | ||
| * [simeon] What is the status of automated testing of extension APIs? | ||
| * [timothy] We don't have support for that yet in Safari, but will look into developing the primitives to enable the prototype that Patrick built to work. | ||
| * TPAC 2024 | ||
| * [timothy] TPAC 2024 is in Anaheim. | ||
| * [simeon] We were waiting until an official announcement was made. | ||
| * [oliver] Registration is already open. | ||
| * [timothy] Without official announcement we cannot book the specific day, but if you are interested in participating you may as well register now. | ||
|
|
||
| The next meeting will be on [Thursday, July 4th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6685e600,384) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters