-
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 #305 from w3c/meeting-2022-10-27
Publish minutes of 2022-10-27 meeting
- Loading branch information
Showing
2 changed files
with
146 additions
and
3 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,142 @@ | ||
| # WECG Meetings 2022, Public Notes, Oct 27 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PSDT = https://everytimezone.com/?t=6359ca00,384 | ||
| Call-in details: [WebExtensions CG, 27th October 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20221027T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #297](https://github.com/w3c/webextensions/issues/297), [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 292](https://github.com/w3c/webextensions/issues/292): Inconsistency: StorageArea callback order | ||
| * [Issue 293](https://github.com/w3c/webextensions/issues/293): Transfer huge data blobs between service worker and content script instantly | ||
| * [Issue 294](https://github.com/w3c/webextensions/issues/294): Proposal: one-time message passing addressed to a specific documentId or contextId | ||
| * [Issue 295](https://github.com/w3c/webextensions/issues/295): extension.getBackgroundPage, runtime.getBackgroundPage, and serviceWorkers | ||
| * [Issue 296](https://github.com/w3c/webextensions/issues/296): i18n.getMessage() language fallback paths | ||
| * [Issue 298](https://github.com/w3c/webextensions/issues/298): Clarification: Deprecation Policy for Browser Extensions | ||
| * [Issue 300](https://github.com/w3c/webextensions/issues/300): Proposal: Improve the browser.commands API | ||
| * [Issue 301](https://github.com/w3c/webextensions/issues/301): \_execute_action, \_execute_browser_action and \_execute_page_action commands | ||
| * [Issue 302](https://github.com/w3c/webextensions/issues/302): Blocking webRequest use case: DNR unable to properly redirect based on URL parameters | ||
| * [Issue 303](https://github.com/w3c/webextensions/issues/303): Default to using https for requests from extensions, e.g. via CSP | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * (From the [Agenda ticket, Giorgio Maone](https://github.com/w3c/webextensions/issues/297#issuecomment-1281019233)): I'd like to revisit[ #103](https://github.com/w3c/webextensions/issues/103), and especially "Script Injection in WorkerScope", a topic discussed exactly[ one year ago](https://github.com/w3c/webextensions/blob/50d2e7aa94ae4ed41ad420268fd451b73d1e15cc/_minutes/2021-10-28-wecg.md), which the group was apparently quite supportive of but AFAIK didn't actually go anywhere | ||
| * [rob] Note: we ran out of time and did not discuss it this time. Will revisit next meeting. | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Giorgio Maone (NoScript, Tor) | ||
| 3. Carlos Jeurissen (Jeurissen Apps) | ||
| 4. Timothy Hatcher (Apple) | ||
| 5. David Johnson (Apple) | ||
| 6. Tomislav Jovanovic (Mozilla) | ||
| 7. Oliver Dunk (1Password) | ||
| 8. Brian Weinstein (Apple) | ||
| 9. Manvel Saroyan (Bardeen) | ||
| 10. Benjamin Bruneau (1Password) | ||
| 11. Annie Chen (1Password) | ||
| 12. Richard Worth (Capital One) | ||
| 13. Lucas Selker (Dashlane) | ||
| 14. Sam Macbeth (DuckDuckGo) | ||
| 15. Bradley Cushing (Dashlane) | ||
| 16. Tyler Carson (Keeper) | ||
| 17. Todd Schiller (PixieBrix) | ||
| 18. Tim Heflin (Keeper) | ||
| 19. Jack Works (Sujitech) | ||
| 20. Mukul Purohit (Microsoft) | ||
| 21. James Hycner (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 292](https://github.com/w3c/webextensions/issues/292): Inconsistency: StorageArea callback order | ||
|
|
||
| * [timothy] Report about storageArea calls not being in the order. | ||
| * [timothy] Discussion in the issue; in Safari the order is non-deterministic. | ||
| * [carlos] (partly inaudible) The APIs generally imply there should be a specific order for write-operations. Yet the question here is if storageArea.get should wait until write-operations are finished. Doing so could lead to less bugs due to incorrect assumptions, however not doing so has performance benefits. | ||
| * [rob] In Firefox API calls are generally processed in order, but that is on a best-effort basis. There is no guarantee, especially between different methods. | ||
| * [simeon] I'm surprised to see the first example working. The platform does not make any guarantees about this. | ||
| * [timothy] I'll look into updating Safari's implementation to improve the ordering. | ||
| * [simeon] I would advise against specifying/guaranteeing the behavior, since that increases the complexity of implementation. | ||
| * Consensus: no guarantees | ||
|
|
||
| [Issue 293](https://github.com/w3c/webextensions/issues/293): Transfer huge data blobs between service worker and content script instantly | ||
|
|
||
| * [rob] (Mozilla/Firefox): I am supportive of using the fast performant web platform-based mechanisms to transfer messages. | ||
| * [simeon] (Google/Chrome): I agree. | ||
| * [rob] Restrict to sending to a specific frame (tabs.sendMessage/runtime.sendMessage broadcasts everywhere). Even if it is just support for the “MessagePort” web platform API being accepted in a message. | ||
| * [simeon] Similar to BroadcastChannel. | ||
| * [rob] I don't think that transferables can be supported in BroadcastChannel. | ||
| * [timothy] (Apple/Safari): In favor of supporting this capability. | ||
|
|
||
| [Issue 294](https://github.com/w3c/webextensions/issues/294): Proposal: one-time message passing addressed to a specific documentId or contextId | ||
|
|
||
| * [timothy] Chrome was working on documentId. | ||
| * [simeon] We are close if not already shipping documentId. For reference, we have a related blog post in the works in this pull request: https://github.com/GoogleChrome/developer.chrome.com/pull/3903 | ||
| * Participants need to read the issue, and will revisit this at the next meeting. | ||
|
|
||
| [Issue 295](https://github.com/w3c/webextensions/issues/295): extension.getBackgroundPage, runtime.getBackgroundPage, and serviceWorkers | ||
|
|
||
| * _(see issue for background)_ | ||
| * [timothy] Discussed on the issue; we've fixed the bug in Safari. | ||
| * [simeon] One of the key improvements of Service workers is their independence of the main thread. | ||
| * [rob] Note that there's a behavior difference between runtime.getBackgroundPage and extension.getBackgroundPage in Firefox. The former will wake up the event page if needed, the latter may return null in that case. | ||
| * [timothy] Should we add a label to follow up on this in the next manifest version? | ||
| * [carlos] Depends on what you want to achieve. Are we intending to remove this capability in the future? | ||
| * [rob] The issue has multiple questions and remarks. It is not clear what “neutral”, “opposed” or “supportive” would mean. Since we've completed the discussion, could we close the issue? And file follow-ups for the actionable parts of the issue. | ||
| * [carlos] Yes. | ||
| * [simeon] I'll split the issue. | ||
|
|
||
| [Issue 296](https://github.com/w3c/webextensions/issues/296): i18n.getMessage() language fallback paths | ||
|
|
||
| * [carlos] Inconsistencies between browsers, see issue. | ||
| * [rob] default_locale is documented to be the fallback. That's clear. If we were to fall back to other languages in between, that could potentially be surprising. | ||
| * [timothy] Safari will read all three locale files (default, region-specific and language), and merges them into one dictionary. This seems to match Chrome. | ||
| * [tomislav] (Firefox): We will investigate this, and be supportive of this if this is the convention for language fallback handling. | ||
| * [simeon] FYI: [Language Tags and Locale Identifiers for the World Wide Web (w3.org)](https://www.w3.org/TR/ltli/) | ||
|
|
||
| [Issue 298](https://github.com/w3c/webextensions/issues/298): Clarification: Deprecation Policy for Browser Extensions | ||
|
|
||
| * [timothy] We will support extensions as long as possible. | ||
| * [simeon] This has been on my mind. E.g. [issue 303](https://github.com/w3c/webextensions/issues/303) reminded me of the need for this. | ||
| * [tomislav] We have an official deprecation policy (https://wiki.mozilla.org/WebExtensions/DeprecationPolicy), but we try to avoid breaking where possible. For MV2->MV3 transition we have an even longer timeline. | ||
| * [rob] For clarity, we don't yet have a set plan to deprecate MV2. Our plan is to revisit this later and provide at least one year of notice. | ||
|
|
||
| [Issue 300](https://github.com/w3c/webextensions/issues/300): Proposal: Improve the browser.commands API | ||
|
|
||
| * Read this and revisit the next meeting. | ||
|
|
||
| [Issue 301](https://github.com/w3c/webextensions/issues/301): \_execute_action, \_execute_browser_action and \_execute_page_action commands | ||
|
|
||
| * [carlos] Chrome does not migrate shortcuts when \_execute\*\_action commands are used. They should be treated as equivalent to to ease migration. | ||
| * [timothy] Safari does not support the ability to register shortcuts yet, so this does not apply to Safari. | ||
| * [simeon] I'm trying to anticipate the perspective of the team. We'd be disinclined to merge the browser_action and page_action into action, since this is a new API and merging may be a longer term maintenance burden. | ||
| * [rob] The issue here is that Chrome's MV3 forces extension devs to replace browser_action and page_action with action. Users that have previously customized the shortcut via the browser's UI will lose their customizations if the browser does not migrate the customized shortcut from \_execute_browser_action to \_execute_action. | ||
| * [simeon] Ok. That sounds like a bug. I'll follow up with Chrome. | ||
| * [rob] We should also make sure to verify that this works correctly in Firefox. | ||
|
|
||
| [Issue 302](https://github.com/w3c/webextensions/issues/302): Blocking webRequest use case: DNR unable to properly redirect based on URL parameters | ||
|
|
||
| * [alexei] The DNR API lacks the ability to decode URL query parameters. | ||
| * [rob] I am supportive of this capability, provided that there is an API that we can all agree upon. Preferably with an API that can support more kinds of transformations if desired in the future (e.g. url encode / url decode). | ||
| * [simeon] I personally like the idea. I'll ask the team and get back (chrome:followup). | ||
|
|
||
| [Issue 303](https://github.com/w3c/webextensions/issues/303): Default to using https for requests from extensions, e.g. via CSP | ||
|
|
||
| * [rob] Proposal to upgrade http to https. | ||
| * [simeon] (Chrome) I checked in with Devlin, but he didn't have objections. So supportive. | ||
| * [tomislav] Sending user data to http is already forbidden by the extension stores. So this change would also help the extension stores to more effectively enforce their policies. | ||
| * [rob] Not all requests are about user data, so there is an opt out for this feature. | ||
| * [rob] Note that we also need to consider the desired behavior when an extension has requested `http:-` host permissions but not https. Upgrading requests without having granted https:-permission would result in the request being blocked for the lack of permissions. Note that the permission warnings (e.g. in Chrome and Firefox) don't even show the scheme to users, so an option is to also grant https permissions when http is specified. | ||
|
|
||
| The next meeting will be on [Thursday, November 10th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=6359ca00,384). Note: daylight saving time changes, from PDT to PST. Meeting starts at 4 PM UTC instead of 3 PM UTC. This is still 5 PM CET. |
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