-
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.
Publish minutes of 2023-01-19 meeting
- Loading branch information
Showing
2 changed files
with
155 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,152 @@ | ||
| # WECG Meetings 2023, Public Notes, Jan 19 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=63c88800,3c0 | ||
| Call-in details: [WebExtensions CG, 19th January 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Check in on PRs** | ||
| * [PR 331](https://github.com/w3c/webextensions/pull/331): Add User Scripts API proposal | ||
| * [PR 334](https://github.com/w3c/webextensions/pull/334/): New API proposal : extension.getContexts() | ||
| * **Carry-over from previous meetings** | ||
| * [Issue 339](https://github.com/w3c/webextensions/issues/339): Inconsistency: Proxy Bypass list | ||
| * **Other new issues** | ||
| * None! | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 311](https://github.com/w3c/webextensions/issues/311): Ability to unload the background script from SW code [regression from MV2] | ||
| * [Issue 162](https://github.com/w3c/webextensions/issues/162): Declarative Net Request proposal: disable individual static rules | ||
| * [Issue 269](https://github.com/w3c/webextensions/issues/269): declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default | ||
| * [Issue 318](https://github.com/w3c/webextensions/issues/318) and [Issue 319](https://github.com/w3c/webextensions/issues/319): Adjusting limits on enabled static rulesets, enabled rulesets, dynamic rules | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * Regular expressions in DNR API (regexFilter) | ||
| * Declarative cosmetic rules API | ||
| * [search.search](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/search/search) vs [search.query](https://developer.chrome.com/docs/extensions/reference/search/#method-query) API (Firefox [bug 1804357](https://bugzilla.mozilla.org/show_bug.cgi?id=1804357)) | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Tomislav Jovanovic (Mozilla) | ||
| 3. Simeon Vincent (Google) | ||
| 4. David Johnson (Apple) | ||
| 5. Timothy Hatcher (Apple) | ||
| 6. Carlos Jeurissen (Jeurissen Apps) | ||
| 7. Luke Selker (Dashlane) | ||
| 8. Tim Heflin (Keeper) | ||
| 9. Oliver Dunk (Google) | ||
| 10. Sam Macbeth (DuckDuckGo) | ||
| 11. Mukul Purohit (Microsoft) | ||
| 12. Andrey Meshkov (AdGuard) | ||
| 13. Maxim Topciu (AdGuard) | ||
| 14. Benjamin Bruneau (1Password) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [PR 331](https://github.com/w3c/webextensions/pull/331): Add User Scripts API proposal | ||
|
|
||
| * [timothy] What's needed before merging this? | ||
| * [rob] Recently there has been a long discussion on https://github.com/w3c/webextensions/pull/331#discussion_r1048532828. I updated the TOC at the original issue (https://github.com/w3c/webextensions/issues/279#issuecomment-1254094148) to link to this and specific parts of the thread about the requirements and API design. I see a very recent update to the PR; I haven't updated it yet. | ||
| * [timothy] Strawman proposal for how we approach merging proposals like this is an editor and chair approve. | ||
| * [tomislav] Took a quick look at the update and I didn't see anything addressing synchronous communication between user scripts and the main world. | ||
| * [rob] While I haven't reviewed PR yet, this was mentioned as future work in [Devlin's comment with an API proposal update](https://github.com/w3c/webextensions/pull/331#discussion_r1063008585). | ||
| * [simeon] I'm onboard with a chair or editor approving. What is the guiding principle behind the approvals? What does it signal? | ||
| * [timothy] No major controversy/disagreement with the shape of the proposal as it stands. Possibly use a label to help communicate intent for this stage. | ||
| * [tomislav] This is flagged as a proposal, so in [mozilla standard positions](https://github.com/mozilla/standards-positions)-speak, not being “harmful” would be a minimum bar. This is the case here. | ||
| * [rob] In this case I hadn't signed off yet because I felt there were outstanding concerns with the proposal that endanger the usefulness of the API to extension API devs, but with the recent changes introduced by Devlin I believe those concerns have been addressed. | ||
| * [timothy] Approval here is not reflective of who we work for, but whether it fits in the direction of the WECG. | ||
| * Next step here is to review the updated PR. | ||
| * [rob] Another action item is to codify this process in the [How we work section of CONTRIBUTING.md](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#how-we-work). | ||
| * [timothy] I will do that. | ||
| * [timothy] Simeon, were you also going to create an API proposal template? | ||
| * [simeon] Yes, just created https://github.com/w3c/webextensions/issues/342 to track that work. | ||
|
|
||
| [PR 334](https://github.com/w3c/webextensions/pull/334/): New API proposal : extension.getContexts() | ||
|
|
||
| * [timothy] This is an API proposal for a replacement of extension.getViews(). Rob has already left several comments. | ||
| * [timothy] [One of Rob's comments](https://github.com/w3c/webextensions/pull/334#discussion_r1068070468) is about continuing to use the “incognito” property instead of introducing a second one. This makes sense to me. | ||
| * [simeon] Agreed that we should use browser-neutral names for new APIs. | ||
| * [simeon] Should we come up with a deprecation policy? | ||
| * [timothy] It would probably be useful to have a running document/label to keep track of things that would be nice to change at the next manifest version (e.g. MV4). | ||
| * [rob] I wouldn't recommend changing established APIs under the guise of browser name neutrality, because it would do more harm than good. It would invalidate existing documentation, examples and extensions. | ||
| * [tomislav] I'm in favor of using neutral names for new things, but agree with Rob that there is no significant value in renaming “old” things. | ||
| * [timothy] I'm thinking of a deprecation approach like introducing a second name (e.g. incognito + private) and then eventually deprecate “incognito” in the far future. | ||
| * [simeon] I do want to think about having a consistent platform and balance that against churn in the platform. | ||
| * [tomislav] For this case, should we support both incognito and private? | ||
| * [rob] I would not do that for just one API. If there is interest, we should do it wholesale for all APIs, not just one or a few APIs. | ||
| * [timothy] Agreed with that. We should file a new standalone proposal. | ||
| * [simeon] I think we should should hold off with that kind of change until we are able to discuss and align on a plan for how we approach API consistency and breaking changes. | ||
| * [timothy] Any outstanding concerns with this proposal? | ||
| * [rob] Mostly just renaming properties for clarity. Mostly minor stuff. Need to review and provide feedback before approving. | ||
|
|
||
| [Issue 339](https://github.com/w3c/webextensions/issues/339): Inconsistency: Proxy Bypass list | ||
|
|
||
| * [timothy] I'm not familiar with this; we don't support this in Safari. | ||
| * [simeon] I don't have enough context to comment here. Let's continue the discussion async. | ||
| * [timothy] Let's revisit next meeting. | ||
|
|
||
| [Issue 311](https://github.com/w3c/webextensions/issues/311): Ability to unload the background script from SW code [regression from MV2] | ||
|
|
||
| * [rob] When we last discussed this, the action item was on Simeon to reach out to other Chromium engineers to discuss introducing a close method. | ||
| * [simeon] Lost track of this. I will reach out to engineers on my side this week. | ||
|
|
||
| [Issue 162](https://github.com/w3c/webextensions/issues/162): Declarative Net Request proposal: disable individual static rules | ||
|
|
||
| * [simeon] The development of this has been taken over from Felipe by Byungwoo. | ||
| * [simeon] We merged patches to introduce two new methods: updateStaticRules and getDisabledRuleIds. | ||
| * [andrey] I already commented on the issue and want to repeat: Is it possible to raise the limit of disabled rules? | ||
| * [simeon] The limits are a subject of another topic later today (issue 318 / issue 319). | ||
| * [simeon] I will discuss this with the relevant engineers in more detail to figure out what we can do here. | ||
| * [timothy] What is the constraints that lead to Chrome coming up with the limits? | ||
| * [simeon] From recollection, memory limits are constraints. | ||
| * [timothy] From Felipe's comment, the implementation tries to avoid recompiling rules and does that by maintaining a data structure with the rules. | ||
| * [simeon] Might be useful for our process to get feedback from other browsers on their concerns for increasing rule limits. | ||
| * [rob] At an abstract level there are two aspects here: checking whether the ruleId integer is part of a set, and resuming the DNR rule evaluation process when the implementation detects that a rule is disabled. If the latter is expensive, a limit is somewhat sensible. Limiting solely to minimize the set of disabled rules may be too eager. The application of limits seems somewhat arbitrary: e.g. requestDomains can take an arbitrary number of domain strings even though that may have a larger impact than a set of integers. | ||
| * [timothy] We basically have one big rule count for each extension: 150,000 limit across static, dynamic, etc. That limit was primarily targeting low end iPhone memory limits. | ||
| * [simeon] How does Safari handle situations where a user has N extensions installed, each of which consume the maximum quota. | ||
| * [timothy] Safari does not have a global limit. | ||
|
|
||
| [Issue 269](https://github.com/w3c/webextensions/issues/269): declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default | ||
|
|
||
| * [timothy] We were all in favor and were waiting for Simeon to follow up with Chrome. | ||
| * [simeon] We are onboard with the change. There was a concern with compiled vs not compiled, but we are still onboard. This is a breaking change, so we need to get a word out. That outreach is the primary blocker on the Chrome side. | ||
| * [tomislav] The proposed default has a lower risk of breaking than switching the defaults around. | ||
| * [andrey] There are few extensions. | ||
| * [rob] So we have repeated our approval of this proposal. Can we track these changes on our own issue trackers to make sure that this actually gets implemented? Especially with the few extensions potentially impacted right now, it makes sense to. | ||
| * [timothy] I filed a Safari-side issue. | ||
| * [simeon] Scheduling this on my side. | ||
|
|
||
| [Issue 318](https://github.com/w3c/webextensions/issues/318) and [Issue 319](https://github.com/w3c/webextensions/issues/319): Adjusting limits on enabled static rulesets, enabled rulesets, dynamic rules | ||
|
|
||
| * [timothy] Skipped because this was discussed before with issue 162. | ||
|
|
||
| Regular expressions in DNR API (regexFilter) | ||
|
|
||
| * [simeon] I want to gather information on the challenges that developers face in Chrome's regexFilter. Chrome has a memory limit on the regex, which is the constraining factor of the regexp. | ||
| * [rob] Chrome's memory limit is 2kb, at most 1000 regexes at the moment. | ||
| * [simeon] I'd like to receive feedback from the other vendors on how browsers handle regexp rules. | ||
| * [timothy] In Safari, every rule is compiled to a regex rule. We limit complexity, but don't know the details on these limits. | ||
| * [andrey] Chrome's implementation does not allow negative look-aheads. Safari has a lot of limits. | ||
| * [rob] I'm familiar with limits in both Chrome and Safari. Would be helpful to have an issue to gather information on requirements from extension developers. I can post what I know about Chrome and Safari's implementation constraints. In Safari, the regular expression is compiled to a state machine, so there are limits on what it can do. I'm willing to postpone Firefox's regexFilter implementation until a resolution on this. | ||
| * [simeon] Chromium uses RE2 and has a strong preference to minimize the number of | ||
| * [rob] My current idea is to validate the complexity of the regexFilter, independently of the underlying regex engine. Disconnecting the regex input requirements from the actual implementation makes it more feasible to standardize on a common regexp format AND to potentially increase the limits. | ||
| * [rob] I will create a new issue to start the discussion on the desired format of regexFilter. | ||
|
|
||
| Declarative cosmetic rules API | ||
|
|
||
| * [andrey] Is there interest in this? | ||
| * [timothy] This would be easy to implement in Safari. | ||
| * [rob] Please file a new issue so that we can discuss it at the next meeting. | ||
|
|
||
| [search.search](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/search/search) vs [search.query](https://developer.chrome.com/docs/extensions/reference/search/#method-query) API (Firefox [bug 1804357](https://bugzilla.mozilla.org/show_bug.cgi?id=1804357)) | ||
|
|
||
| * [rob] We ran out of time and did not discuss this topic. | ||
|
|
||
| The next meeting will be on [Thursday, February 2nd, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=63dafd00,3c0). |
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