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

Publish minutes of 2021-11-11 meeting #135

Merged
merged 1 commit into from
Nov 17, 2021
Merged

Publish minutes of 2021-11-11 meeting #135

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
149 changes: 149 additions & 0 deletions _minutes/2021-11-11-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,149 @@
# WECG Meetings 2021, Public Notes, Nov 11

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PST = [https://everytimezone.com/?t=6179e800,384](https://everytimezone.com/?t=618c5d00,3c0)
Call-in details: [WebExtensions CG, 11th November 2021 event](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20211111T080000)
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)

* **Carry over from previous meetings**
* Would be good to invite somebody from Google who can speak about Google's MV3 SW plans. (Alexei)
* Split up discussions about SW plans into two groups. (Carlos)
* 1. Missing APIs and functionality in extension serviceWorkers. [#72](https://github.com/w3c/webextensions/issues/72) and a proposal [#134](https://github.com/w3c/webextensions/issues/134)
* 2. Lack of the persistence of background scripts. See: [#44](https://github.com/w3c/webextensions/issues/44)
* Do browser vendors have plans for addressing WASM startup times in MV3? (Oliver Dunk)
* **Topics**
* [Proposal: add optional_host_permissions #119](https://github.com/w3c/webextensions/issues/119)
* [Manifest keys cleanup #122](https://github.com/w3c/webextensions/pull/122)
* [Proposal: Limited Event Pages for MV3 #134](https://github.com/w3c/webextensions/issues/134)
* runtime.getFrameId proposal() [#12 comment](https://github.com/w3c/webextensions/issues/12#issuecomment-930545112)
* Unique frame ids, frame messaging and getting frameId from window objects. [#90](https://github.com/w3c/webextensions/issues/90), [#12](https://github.com/w3c/webextensions/issues/12), [#77](https://github.com/w3c/webextensions/issues/77), [#91](https://github.com/w3c/webextensions/issues/91) (Carlos)
* **Other new issues**
* [Proposal: agree on a unified sidebar_action API for mv3 #128](https://github.com/w3c/webextensions/issues/128)
* [Documentation: get a complete list of all locales supported in each browser #131](https://github.com/w3c/webextensions/issues/131)
* [Determine what manifest properties every vendor agrees on #121](https://github.com/w3c/webextensions/issues/121)
* [Proposal: add disallow_host_permissions #123](https://github.com/w3c/webextensions/issues/123)
* [Inconsistency: scripting.registerContentScripts and contentScripts.register #125](https://github.com/w3c/webextensions/issues/125)
* [Proposal: add runtime.openShortcutsPage #126](https://github.com/w3c/webextensions/issues/126)
* [Proposal: keep browser_action and do not rename it to action #127](https://github.com/w3c/webextensions/issues/127)
* [Proposal: allow extensions to register web share targets #132](https://github.com/w3c/webextensions/issues/132)
* [Messenger needs persistent background context #133](https://github.com/w3c/webextensions/issues/133)


## Attendees (sign yourself in)

1. Simeon Vincent (Google)
2. Oliver Dunk (1Password)
3. Rob Wu (Mozilla)
4. Alexei (Privacy Badger)
5. Tomislav Jovanovic (Mozilla)
6. Carlos Jeurissen (Jeurissen Apps)
7. Timothy Hatcher (Apple)
8. Nick McGuire (1Password)
9. Brandon Lucier (1Password)
10. Sam Macbeth (DuckDuckGo)
11. Stuart Colville (Mozilla)
12. Mukul Purohit (Microsoft)
13. Maxim Topciu (AdGuard)
14. Krzysztof Modras (Ghostery)
15. Giorgio Maone (NoScript)


## Queue (add yourself at the bottom)

* <add yourself>


## Meeting notes

Would be good to invite somebody from Google who can speak about Google's MV3 SW plans. (Alexei)

* [simeon] Chatted with Devlin. He is tentatively planning to join the next meeting (in four weeks, since the next one in two weeks is scheduled due to Thanksgiving.
* [alexei] Google has given a timeline, with the appearance that MV3 is stable. The community response has been largely negative. Wonderful that Devlin can join us. Would like to have a discussion to discuss the trade-offs and whether they make sense.
* [carlos] Suggest to split SW discussion in two parts (1) missing APIs ([#72](https://github.com/w3c/webextensions/issues/72) and proposal [#134](https://github.com/w3c/webextensions/issues/134)) and (2) lack of persistent background scripts (e.g. [#44](https://github.com/w3c/webextensions/issues/44)).
* [simeon] [tomislav] [timothy] Agreed, this makes sense.

Do browser vendors have plans for addressing WASM startup times in MV3? (Oliver Dunk)

* [simeon] Aware of this concern and investigating, but too early to make commitments.
* [oliver] We use WebAssembly in our extension, and this causes a noticeable delay at startup, to the point that we may have to reconsider using WebAssembly in favor of JS.
* [nick] The non-persistent background page forces us to re-initialize WASM all the time. It would be nice if it's possible to keep some WASM state between sessions.
* [simeon] Utility in discussing it here is mostly making sure that browser vendors are aware of and considering these use cases.
* [timothy] Also speaks to concern around startup times and optimizations in general.

[Issue 119](https://github.com/w3c/webextensions/issues/119): Proposal: add optional_host_permissions

* [simeon] Not formed a final decision, but amenable to the idea.
* [tomislav] Not decided to commit yet either, but the idea makes sense. Not necessary to support a new key, could re-use optional_permissions.
* [simeon] Intentionally moved host_permissions outside of optional_permissions, would like to have a separate optional_host_permissions.
* [carlos] Please let optional_host_permissions take precedence over host_permissions; browsers that support it can treat it as optional; other browsers can use host_permissions instead.
* [timothy] In favor of supporting optional_host_permissions in Safari.

[PR 122](https://github.com/w3c/webextensions/pull/122): Manifest keys cleanup

* Part of [issue 121](https://github.com/w3c/webextensions/issues/121) (Determine what manifest properties every vendor agrees on).
* [simeon] Concerned about losing the existing content, but it's in the revision history if needed.
* [tomislav] will review after meeting.
* [timothy] externally_connectable is supported in Safari, so that should be kept since we have at least 2 implementations. We also support devtools_page.
* [tomislav] Yes, we previously agreed that the criteria is to have at least two implementations.

[Issue 134](https://github.com/w3c/webextensions/issues/134): Proposal: Limited Event Pages for MV3

* [tomislav] We at Mozilla believe that support for event pages is a good way to help developers to transition from a persistent background page to a context that may not stay alive forever. We will start prototyping this in the coming weeks.
* [timothy] We (Safari) support this proposal. We already require non-persistent background pages in Safari on mobile, and allowing event pages in MV3 is less friction for developers.
* [simeon] At the Chrome side are currently not supporting this proposal. In 4 weeks from now, Devlin will join to explain and discuss the trade-offs.
* [krysztof] Would like a written statement from Google that explains the decisions.
* [carlos] Issues could be created
* [rob] These meeting notes are the written record of these meetings.
* [carlos] The use of “persistent” in the manifest prevents extensions from loading in Safari on iOS - https://developer.apple.com/forums/thread/691542
* [timothy] We currently require the persistent flag to be set to false, to ensure that extensions are designed for non-persistency. We are supportive of one manifest that works in all browsers, and as mentioned in previous meetings a warning rather than an error may be preferred.

[Issue 12](https://github.com/w3c/webextensions/issues/12): runtime.getFrameId proposal()

* [tomislav] https://github.com/w3c/webextensions/issues/12#issuecomment-930545112
* [simeon] Would like to prototype, but we also need to consult other groups (e.g. security review), and this is not a fast process.
* [tomislav] Believes that Devlin's comment concerns implementation details, rather than design issues. Will start prototyping.
* [rob] Raised the issue of embed not having a contentWindow getter at https://github.com/whatwg/html/issues/7140. Their consensus is to not add a new embed.contentWindow getter because embed is a legacy element. The options available are to either (1) let getFrameId take `<embed>` elements as a parameter, or (2) add an extension-only embed.contentWindow getter.
* [timothy] Supportive of (1). An embed.contentWindow getter is not preferred for implementation reasons.
* [rob] Chrome's implementation for shadow root getters was added to a chrome.dom namespace instead of an element getter like Firefox, so although Simeon cannot speak to the implementation right now, it's probably safe to assume that Chrome would prefer (1) over (2).

Unique frame ids, frame messaging and getting frameId from window objects. [#90](https://github.com/w3c/webextensions/issues/90), [#12](https://github.com/w3c/webextensions/issues/12), [#77](https://github.com/w3c/webextensions/issues/77), [#91](https://github.com/w3c/webextensions/issues/91) (Carlos)

* [carlos] #77, send messages directly to frames. #91, addresses the issue of executeScript/insertCSS
* [simeon] Concern with 91, frameid does not uniquely identify a frame
* [tomislav] Too many assumptions that tabId is 0 or -1. New scripting API's executeScript taking an object introduces the possibility of more flexibility in specifying execution context. Might be able to figure out an alternate way to target. Hesitant to promise window ID could be used as they're separate kinds of IDs. There are ways to uniquely identify a popup.

[Issue 128](https://github.com/w3c/webextensions/issues/128): Proposal: agree on a unified sidebar_action API for mv3

* [carlos] Reached out to Opera. Got approval for participation from a member of their team.
* [tomislav] Difference between Firefox and Opera is primarily the shape of the manifest definition. Should discuss more in the issue and possibly offline. Feel free to put them in contact with me

[Issue 131](https://github.com/w3c/webextensions/issues/131): Documentation: get a complete list of all locales supported in each browser

* [carlos] asking browser vendors to follow up with information and participate in this issue
* [timothy] Safari is not represented in the spreadsheet & relies on underlying OS. You would be interested in specifying a specific fallback order, correct?
* [carlos] Yes, can be followed up in a separate issue.
* [mukul] Are you looking at having a consistent fallback scheme across all browsers and OSs?
* [carlos] Yes, want a well-defined path.
* [tomislav] I expect this behavior to be the same as the resolution process for pages. May be best to bring in experts from that realm
* [carlos] Practical request is to have a list for developers on what language codes are/are not supported

[Issue 125](https://github.com/w3c/webextensions/issues/125): Inconsistency: scripting.registerContentScripts and contentScripts.register

* [rob] Recognizes incompatibility. Firefox will move to scripting API, which is currently being implemented. Found minor issues with Chrome's implementation, will reach out separately to Google, and if any specification-worthy issue comes up I'll file an issue here.

[Issue 132](https://github.com/w3c/webextensions/issues/132): Proposal: allow extensions to register web share targets

* [carlos] Issue raised during Chrome Dev Summit to have extensions be a share target
* [simeon] did a small amount of investigation, looks like it's only defined in the PWA manifest. Assume we should adopt a similar implementation and leverage existing web platform capabilities
* [timothy] Initial thought looking at the PWA world is that this would likely be defined very differently in the extension world. Similar end user UX, but likely little overlap with PWA
* [tomislav] Agree with Timothy's assessment.
* [timothy] If someone wants to come up with a proposal, that would be awesome.

(ran out of time for the other topics)

The next meeting will be on [Thursday, December 9th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=61b14700,3c0). Note that we are skipping the originally scheduled meeting on November 25th.
5 changes: 3 additions & 2 deletions _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

* 2021-11-11 at 8 AM PST = https://everytimezone.com/?t=618c5d00,3c0
* 2021-11-25 at 8 AM PST = https://everytimezone.com/?t=619ed200,3c0
* 2021-12-09 at 8 AM PST = https://everytimezone.com/?t=61b14700,3c0
* 2022-01-06 at 8 AM PST = https://everytimezone.com/?t=61d63100,3c0

## Past meetings

* 2021-11-11 ([minutes](2021-11-11-wecg.md))
* 2021-10-28 ([minutes](2021-10-28-wecg.md))
* 2021-10-14 ([minutes](2021-10-14-wecg.md))
* 2021-09-30 ([minutes](2021-09-30-wecg.md))
Expand Down