-
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 #348 from w3c/meeting-2023-02-02
Publish minutes of 2023-02-02 meeting
- Loading branch information
Showing
2 changed files
with
150 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,147 @@ | ||
| # WECG Meetings 2023, Public Notes, Feb 2 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=63dafd00,3c0 | ||
| Call-in details: [WebExtensions CG, 2nd February 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230202T080000) | ||
| 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. | ||
|
|
||
| * **Meta** | ||
| * Changes to Chrome's representation | ||
| * **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 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
| * Declarative cosmetic rules API | ||
| * **Other new issues** | ||
| * [Issue 347](https://github.com/w3c/webextensions/issues/347): Discussion: add a way to show a modal | ||
| * [Issue 346](https://github.com/w3c/webextensions/issues/346): New API: UserSettings.isOnToolbar change event | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * [Chromium issue 1412448](https://bugs.chromium.org/p/chromium/issues/detail?id=1412448): Keyboard shortcuts not being recognized when updating to Manifest V3 | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (formerly Google) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Richard Worth (Capital One) | ||
| 4. Giorgio Maone (NoScript, Tor) | ||
| 5. Oliver Dunk (Google) | ||
| 6. Steven McLintock (1Password) | ||
| 7. Mike Selander (1Password) | ||
| 8. Tim Heflin (Keeper) | ||
| 9. Dmitriy Seregin (AdGuard) | ||
| 10. Timothy Hatcher (Apple) | ||
| 11. Nikita Vasilyev (independent) | ||
| 12. David Johnson (Apple) | ||
| 13. Kiara Rose (Apple) | ||
| 14. Tomislav Jovanovic (Mozilla) | ||
| 15. Maxim Topciu (AdGuard) | ||
| 16. Sam Macbeth (DuckDuckGo) | ||
| 17. Mukul Purohit (Microsoft) | ||
| 18. Emilia Paz (Google) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Changes to Chrome's representation | ||
|
|
||
| * [simeon] I was hit by the 12k layoffs by Google. I'm not representing Google any more, but will continue my role as chair of the group. We'll look into adding a Google representative to the group in the future. | ||
| * [oliver] I joined the Chrome extensions devrel team at Google a few weeks ago. I and others from Google will continue to participate in the WECG. | ||
|
|
||
| [PR 331](https://github.com/w3c/webextensions/pull/331): Add User Scripts API proposal | ||
|
|
||
| * [emilia] Updated the PR a week ago after feedback from the group, in particular on communications between worlds and reducing the CSP of the world. Rob approved with some comments left to address, and called out some aspects such as the namespace to use for the new APIs to the user script world (currently: extension messaging). | ||
| * [rob] We can continue the discussion on the issues, I approved the PR overall. Looks in good shape, we're resolving the last few comments. | ||
| * [emilia] Only a few comments left. I would not mind merging now or later. | ||
| * [rob] Let's resolve these and merge thereafter. | ||
| * [simeon] This is the first major issue where we're establishing our process, and would like to codify them. I (simeon) will follow up with that. | ||
|
|
||
| [PR 334](https://github.com/w3c/webextensions/pull/334/): New API proposal : extension.getContexts() | ||
|
|
||
| * [simeon] Justin handed the work off to Devlin. | ||
| * [oliver] I don't have any updates here. | ||
| * [rob] I have provided feedback and am awaiting an update of the PR. | ||
|
|
||
| [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
|
|
||
| * [rob] Question about regular expressions across browsers for DNR rules. | ||
| * [simeon] Yes, in particular in Chrome's implementation of DNR there is a 2kb limit of compiled regular expressions of the RE2 library. I was curious about other browsers. | ||
| * [rob] It varies by browser, and it's not obvious what to do here. What was the intended follow-up after getting answers to your questions? | ||
| * [simeon] My intent was to follow up to the Chrome team after this, but ran into an issue recently [referring to his layoff]. uBlock Origin's author recently posted a list of regular expressions that did not work in Chrome as concrete examples. | ||
| * [rob] At the last meeting Andrey (from AdGuard) mentioned the intent to add use cases, but I haven't seen that yet. | ||
| * [dmitriy] We (AdGuard) have found a list of regular expressions and will add a comment to the issue. | ||
| * [rob] Next step here is to wait for more use cases from extension devs and filter list devs. | ||
|
|
||
| [Issue 347](https://github.com/w3c/webextensions/issues/347): Discussion: add a way to show a modal | ||
|
|
||
| * [simeon] An issue to create a panel similar to VSCode popup or Arc browser. | ||
| * [nikita] I filed the issue as a follow-up to the last meeting and would like some feedback here. | ||
| * [simeon] Chrome's team would probably be disinclined to do this, because there is no clear distinction between the trusted browser UI and what's been offered here by the extension. | ||
| * [timothy] And today extensions can inject in the page to have the same effect. We could do something that may not necessarily be perceived as more secure, but is actually more secure. | ||
| * [simeon] In the issue it was mentioned that activeTab + commands API can be used. I'd like to not recommend that since it would still grant access to the page. Better than persistent permissions, but the spirit of the issue is to show UI without requiring permissions. | ||
| * [tomislav] I assume that if anything were to be implemented here, that it would probably be tied to activeTab and behave similarly. | ||
| * [tomislav] This is very similar to opening a browserAction popup. That has the advantage of being associated with the extension. I don't see many use cases where this is better suited than the browser action popup. The proposal is more visually appealing, but . | ||
| * [simeon] An issue with the browserAction popup is the maximum size. Multiple developers have called out that on higher-resolution screens (e.g. 4k displays), that the popup only appears on a small part of the screen. | ||
| * [simeon] Historically, the view from Chrome is that while the constraints had been arbitrarily chosen, that the screen in the corner is now part of the expected feature. | ||
| * [tomislav] The size in Firefox is in logical pixels, so not tiny on a big screen. I would not be exposed to expanding that. A potential concern is that the requested feature here has no prior examples in browser UI, so something new would have to be designed. | ||
| * [simeon] I wonder whether we can expand the action popup to have a presentation style attribute to give the browser the choice to handle this, and non-implementing browsers to have the current behavior. | ||
| * [tomislav] That sounds like a reasonable approach to this. | ||
| * [timothy] That also sounds like something that could be user-configurable. E.g. the extension opts in, the user may detach it and make it a floating window - there is native UI to implement this. | ||
| * [nikita] That would work for me, as long as there is a way to attach the popup to the middle of the screen, e.g. by showing a guide or anchor to snap the window to. | ||
| * [oliver] I can imagine use cases. I don't know about a good API to address these, but I can sympathize with the pains due to the lack of support. | ||
| * [tomislav] Is this modal to the page or the browser? If modal to the page, you can still interact with the other tabs. | ||
| * [nikita] Ideally the browser, but it's not that important. | ||
| * [simeon] The current feature can be fully implemented with content scripts. It is not clear whether it's the browser, web page or UI that shows the UI. E.g. an action popup is anchored to the extension action button. There is the “line of death”, anything below that line can potentially be spoofed by content, and anything else above that somewhat trusted. | ||
| * [rob] That concern could be addressed by unconditionally rendering the extension icon + name near/above that line. The extension can still control where their content is being rendered, but the browser maintains the control over the trusted areas and user indicators. | ||
| * [timothy] I am also in favor of the browser being in control of what's being shown. Extensions can opt in / declare their preference (e.g. ability to detach the popup), and the browser then ultimately renders the result while accounting for both the extension and user's preferences. | ||
| * [simeon] If we were to do this, we should ideally offer ways for developers to detect how their UI is going to be rendered. | ||
| * [simeon] It sounds like we're neutral overall. There is a way to provide this kind of feature. What are the next steps? | ||
| * [tomislav] If we can agree to build it as optional preferences on top of action popups, then it could be a way forward. | ||
| * [rob] I don't expect this to be high on the list of priorities for the browser, so if you're very interested in this functionality, patches are welcome: a design and prototype to Chrome and/or Firefox's code bases. | ||
| * [rob] Is there enough information here to put support labels here? | ||
| * [tomislav] Yes, I'll add a comment. | ||
| * [timothy] I'll add a label. | ||
| * [oliver] I'll follow up with the Chrome team. | ||
|
|
||
| Declarative cosmetic rules API | ||
|
|
||
| * [simeon] This came up last session & we ran out of time. | ||
| * [rob] I think Andrey from AdGuard raised this and was planning to open an issue to discuss. | ||
| * [dmitriy] We want to discuss this internally, look at the current state of DNR, and then file a new issue. | ||
| * [rob] And please provide use cases. While it would be nice to account for browser implementations, do not assume a particular implementation. CSS-based rules do not necessarily fit well in the declarativeNetRequest (DNR) API. | ||
| * [simeon] The DNR API is focused on network request modifications, not on content, so it may not be the ideal API to hook on. | ||
| * [timothy] Our original content blocking API does support network blocking and visual CSS blocking in one API, which is probably a potential source of this. | ||
| * [tomislav] And please explain why the existing dynamic content scripts API cannot be used. | ||
| * [timothy] When we implemented this, we found it more feasible to offer a specific API to hide elements, rather than something as broad as injecting arbitrary CSS or even JS. | ||
| * Resolution: Wait for issue to be filed before discussing again. | ||
|
|
||
| [Issue 346](https://github.com/w3c/webextensions/issues/346): New API: UserSettings.isOnToolbar change event | ||
|
|
||
| * [simeon] It is possible to pin items on the toolbar, | ||
| * [tomislav] I'd be supportive of it. | ||
| * [rob] … with the caveat that we (Firefox) do not support this property yet. | ||
| * [timothy] We don't implement the property in Safari either, but I'm supportive of the event. | ||
| * [simeon] I suggest a more generic user settings change event. | ||
| * [tomislav] I support that too. | ||
| * [timothy] Same. | ||
| * [oliver] I'll follow up with the Chrome team. | ||
|
|
||
| [Chromium issue 1412448](https://bugs.chromium.org/p/chromium/issues/detail?id=1412448): Keyboard shortcuts not being recognized when updating to Manifest V3 | ||
|
|
||
| * [simeon] Point of order, we should not be discussing browser specific bugs in these meetings. That having said, this issue may be of interest more broadly to the whole group. | ||
| * [rob] This came up before, in [issue 301](https://github.com/w3c/webextensions/issues/301). I filed a Firefox-specific issue to track this at https://bugzilla.mozilla.org/show_bug.cgi?id=1797811. | ||
| * [steven] We're seeing that when users update from MV2 to MV3, that their keyboard shortcut are no longer being recognized. | ||
| * [oliver] This is a missing migration step that should definitely exist. | ||
| * [simeon] I recall that a few Chrome folks have identified the cause of this issue. | ||
|
|
||
| The next meeting will be on [Thursday, February 16th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=63ed7200,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