Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Publish minutes of 2022-05-12 meeting #211

Merged
merged 1 commit into from
May 20, 2022
Merged

Publish minutes of 2022-05-12 meeting #211

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
128 changes: 128 additions & 0 deletions _minutes/2022-05-12-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
# WECG Meetings 2022, Public Notes, May 12

* Chair: Tomislav Jovanovic
* Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=627c4e00,3c0
Call-in details: [WebExtensions CG, 12th May 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220512T080000)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #209](https://github.com/w3c/webextensions/issues/209), [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

* **Carry-over from previous meetings**
* None
* **Other new issues**
* [Issue 208: Consider common API for push messages across browsers](https://github.com/w3c/webextensions/issues/208)
* [Issue 210: Web Components behaviour in content scripts](https://github.com/w3c/webextensions/issues/210)
* **Open discussion queue (add yourself at the bottom)**
* File Size Limit for submission process (MV3 Firefox) (Tim Heflin)
* **Check-in on ongoing issues**
* [Issue 162: Declarative Net Request proposal: disable individual static rules](https://github.com/w3c/webextensions/issues/162)
* [Issue 188: Inconsistency: Permissions "menus"](https://github.com/w3c/webextensions/issues/188)
* [Issue 197: content_security_policy_report_only](https://github.com/w3c/webextensions/issues/197#issuecomment-1125093836)
* [Issue 97: report_to manifest key](https://github.com/w3c/webextensions/issues/97)


## Attendees (sign yourself in)

1. Tomislav Jovanovic (Mozilla)
2. Rob Wu (Mozilla)
3. Jack Works (Sujitech)
4. Oliver Dunk (1Password)
5. Maxim Tsoy (DuckDuckGo)
6. Carlos Jeurissen (Jeurissen Apps)
7. Richard Worth (Capital One)
8. Bastien Granger (Dashlane)
9. Tim Heflin (Keeper)
10. Bradley Cushing (Dashlane)
11. Larry Xu (Dropbox)
12. Alexei (Privacy Badger)
13. Steven McLintock (1Password)
14. Benjamin Bruneau (1Password)
15. Felipe Erias (Igalia)
16. Mukul Purohit (Microsoft)
17. Simeon Vincent (Google)
18. Jessie Berlin (Apple) (2nd half of meeting only)
19. David Johnson (Apple) (2nd half of meeting only)
20. James Hycner (Keeper)


## Meeting notes

[Issue 208: Consider common API for push messages across browsers](https://github.com/w3c/webextensions/issues/208)

* [oliver] In MV2, push functionality was possible, e.g. with WebSockets. In MV3 with Service workers that's not really feasible. In Chrome the gcm offers an alternative, but in other browsers that's not available. The push API is an alternative in other browsers, but currently not a feasible option because it is tied to notifications.
* [simeon] I [described](https://github.com/w3c/webextensions/issues/208#issuecomment-1122984100) two paths in the issue, 1) an extension API that builds upon the existing push API 2) lean on the existing push API for the web. I believe all browsers currently conflate push messages and notifications, requiring a notification be displayed for each push message
* [tomislav] Adapting the web push API would be preferable, since it allows the re-use of existing infrastructure.
* [oliver] Larry [commented](https://github.com/w3c/webextensions/issues/208#issuecomment-1124555574), may have more thoughts to share.
* [larry] We use HTTP long polling at Dropbox. Use multiple connections for different purposes.
* [simeon] In Chrome we allow multiple registrations; these workers wouldn't have access to the global and need to pass the notification back to the main worker.
* [tomislav] I think the push could potentially come from multiple different servers, it just goes through a single subscription tunnel. My understanding may not be correct.
* [rob] Unfortunate that Apple isn't here to comment, but it looks like Firefox and Chrome think adapting the existing push route is more feasible than a new extension API. Suggest tabling this and revisit this next time (or ask for Apple's opinion async in the issue).
* [oliver] (at end of meeting) Now that we've Apple representation here, any opinion on this issue here?
* [jessie] I'll take this back to the team and respond later.

[Issue 210: Web Components behaviour in content scripts](https://github.com/w3c/webextensions/issues/210)

* [simeon] The fundamental limitation here is the separation of worlds (isolated vs main). The underlying DOM is shared. Custom elements registered from the isolated worlds result in conflicts between the worlds. In Firefox it's possible to selectively expose parts of the worlds, in Chrome it is not.
* [oliver] Another problem I've seen is that even if you have a reference to the element, you can't use methods or properties on that element.
* [tomislav] Are there use cases where it's useful for the content script to interact with the custom elements or the other way around? E.g. Jack, why would you prefer to not have access to the API (mentioned in the issue)?
* [jack] What happens if a custom element is registered in the main world and created in the content script?
* [simeon] If you create a custom element in the main world and try to instantiate it from the isolated world, the isolated world would be unaware of the element.
* [oliver] Use case from 1Password: library that websites can use, content scripts currently has to use other ways to communicate with the element.

File Size Limit for submission process (MV3 Firefox) (Tim Heflin)

* [tim] At upload to AMO the file can be at most 4 MB at submission. In MV3 the background script has to be a single file, can the limit be extended?
* [simeon] You can still compose a background from multiple scripts, such as importScripts.
* [tomislav] We would like to see the use cases and why existing options (importScripts, dynamic imports) cannot be used before figuring out the exact issue. Please file a [Firefox bug submission](https://bugzilla.mozilla.org/enter_bug.cgi?product=WebExtensions&component=General) and need-info me in the bug.
* [rob] Simeon, any limitation on size in Chrome?
* [simeon] Not to my knowledge
* [tomislav] Limitation is in part related to review requirements
* [simeon] On the Chrome side there is the desire to relax the limitations of Service workers in order to allow developers to use dynamic imports from extensions. The current situation where all Service worker code has to be frontloaded is not ideal.
* [jack] Some info for extension devs: If you're using webpack, and want dynamic import in MV3, you can try this plugin => https://github.com/awesome-webextension/webpack-target-webextension/

[Issue 162: Declarative Net Request proposal: disable individual static rules](https://github.com/w3c/webextensions/issues/162)

* [felipe] Working on a design document for the proposal and working with other people to identify issues that cannot be resolved with existing work-arounds. Also [posted](https://github.com/w3c/webextensions/issues/162#issuecomment-1125066774) a prototype patch for Chromium.
* [simeon] I'll ping the relevant engineers so that they're aware of the proposal and work-in-progress implementation.

[Issue 188: Inconsistency: Permissions "menus"](https://github.com/w3c/webextensions/issues/188)

* [rob] Last time we talked about this, the action item was for Simeon to check with the team whether they are interested in (1) replacing contextMenus with menus and (2) changing the API signature of menus.create / contextMenus.create?
* [simeon] Answer is no. Concerns with adding extension menus to the top-level menus, so we decided to keep the existing contextMenus namespace.
* [tomislav] "menus" is also used for Android. Not sure how Safari handles this, but there are other non-context menu surfaces.
* [simeon] Interesting point. I want to continue this conversation with the Chrome team. Personally, in the abstract I like the consolidation on a common, general name.
* [carlos] for compat reasons, Chrome could keep using contextMenus however support menus as an alias. So it's compatible with extensions developed with menus.
* [rob] Ideally we should only have one namespace/permission, so drop one of the other. What's Apple's opinion on this?
* [jessie] If I recall correctly, Firefox supports both menus and contextMenus.
* [rob] That's correct, and ideally we would go back to one since there is no clear benefit for having two, and MV3 offers the opportunity to do so.
* [jessie] Hesitant to pull back a namespace if it's already supported in our MV3 implementation. Need to look more closely before commenting further.
* [rob] If Apple were to keep both namespaces, we would likely do the same.

[Issue 197: content_security_policy_report_only](https://github.com/w3c/webextensions/issues/197#issuecomment-1125093836)

* [jack] Found that I can't use "report only" even using meta tags in a page.
* [oliver] Given the existing content_security_policy key, could we introduce a report_only key to it?
* [simeon] There are multiple policies in the key, e.g. sandbox and extension pages that may need separate report-only directives.
* [rob] Last time this came up concern was raised around exposing data to remote servers via report-to.
* [jack] CSP violation events would also be acceptable.
* [rob] Is there cross-browser interest in this?
* [rob] Firefox: looks reasonable if supported via CSP violation events.
* [simeon] Chrome indicated initial support on the issue https://bugs.chromium.org/p/chromium/issues/detail?id=1315890#c3
* [jessie] Safari: I'll need to discuss this with other Apple engineers first.

[Issue 97: report_to manifest key](https://github.com/w3c/webextensions/issues/97)

* [carlos] Proposed a syntax in the issue.
* [tomislav] Looks reasonable to re-use it in the manifest, not expecting it to be removed from the CSP spec ASAP, but we could support it in extensions. Supportive on Mozilla's end. Timothy (Apple) expressed a favorable response in a [comment](https://github.com/w3c/webextensions/issues/97#issuecomment-1043195351).
* [simeon] Need to go back to the team to ask about this.

https://github.com/w3c/webextensions/issues/155#issuecomment-1125152857

* [mukul] Wanted to quickly mention that we created a GitHub repo to track issues

The next meeting will be on [Thursday, May 26th, 8 AM PST (3 PM UTC)](https://everytimezone.com/?t=628ec300,3c0).
3 changes: 2 additions & 1 deletion _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2022-05-12 at 8 AM PST = https://everytimezone.com/?t=627c4e00,3c0
- 2022-05-26 at 8 AM PST = https://everytimezone.com/?t=628ec300,3c0
- 2022-06-09 at 8 AM PST = https://everytimezone.com/?t=62a13800,3c0

## Past meetings

* 2022-05-12 ([minutes](2022-05-12-wecg.md))
* 2022-04-28 ([minutes](2022-04-28-wecg.md))
* 2022-04-14 ([minutes](2022-04-14-wecg.md))
* 2022-03-31 ([minutes](2022-03-31-wecg.md))
Expand Down