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 2024-01-18 meeting #526

Merged
merged 1 commit into from
Jan 18, 2024
Merged

Publish minutes of 2024-01-18 meeting #526

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

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=65a86a00,3c0
Call-in details: [WebExtensions CG, 18th January 2024](https://www.w3.org/events/meetings/39925102-903a-45c0-9378-71678f05a11b/)
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.

* **Spring Meeting**
* **Carry-over from previous meetings**
* [PR 512](https://github.com/w3c/webextensions/pull/512): update bikeshed build to support multiple bikeshed files
* [PR 508](https://github.com/w3c/webextensions/pull/508): create specification for window.browser
* [Issue 229](https://github.com/w3c/webextensions/issues/229): Extension icons for light/dark/custom theme
* [PR 484](https://github.com/w3c/webextensions/pull/484): Update table with persistence of APIs
* [PR 499](https://github.com/w3c/webextensions/pull/499): action.onUserSettingsChanged proposal
* [PR 370](https://github.com/w3c/webextensions/pull/370): Initial Firefox schemas, 2023Q1
* [Issue 336](https://github.com/w3c/webextensions/issues/336): Inconsistency: action.setIcon() & action.setBadgeBackgroundColor()
* [Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR
* **Other new issues**
* [Issue 524](https://github.com/w3c/webextensions/issues/524): Pre-rendering in new tabs and window ID behavior
* [Issue 460](https://github.com/w3c/webextensions/issues/460): Proposal: declarativeNetRequest: matching based on response headers
* [Issue 515](https://github.com/w3c/webextensions/issues/515): sidePanel API: support "one instance per tab" in openPanelOnActionClick
* [Issue 518](https://github.com/w3c/webextensions/issues/518): Manifest v3 background scripts should not be killed when there are active listeners
* [Issue 519](https://github.com/w3c/webextensions/issues/519): Proposal: Event.addListener should accept an interface.
* (moved remaining issues to the next meeting)
* **Open discussion queue (add yourself at the bottom)**
* (ran out of time, the following topics have not been discussed)
* Rediscussion of [Issue 103](https://github.com/w3c/webextensions/issues/103): arguments and workers in registerContentScripts()
* [Follow up](https://github.com/w3c/webextensions/issues/402#issuecomment-1591619962) on [Issue 402](https://github.com/w3c/webextensions/issues/402): Provide a mean to discriminate initiators and destinations belonging to a local (private) network
* [Issue 454](https://github.com/w3c/webextensions/issues/454): Add a new manifest key to include a origin trial token (anton)
* **Check-in on ongoing issues**
* None


## Attendees (sign yourself in)

1. Giorgio Maone (NoScript, Tor)
2. Patrick Kettner (Google)
3. Anton Bershanskyi (independent)
4. Oliver Dunk (Google)
5. Carlos Jeurissen (Jeurissen Apps)
6. Tomislav Jovanovic (Mozilla)
7. Simeon Vincent (unaffiliated)
8. Rob Wu (Mozilla)
9. Maxim Topciu (AdGuard)
10. David Johnson (Apple)
11. Tim Hatcher (Apple)
12. Mukul Purohit (Microsoft)


## Meeting notes

[Issue 525](https://github.com/w3c/webextensions/issues/525): WECG in-person+online meeting, March 2024

* [timothy] Spring Meeting: Planning to have an in-person meeting for WECG. We had a good experience with meeting in person last year at TPAC 2023. The next meeting is planned to happen on March 18 - 20 in Apple's office at Rancho Bernardo (San Diego, CA). Interested people can sign up. If you do intend to attend, please let us know to enable us to book enough space at the Apple campus.
* [rob] I'll create a Github issue where people can comment.
* [tomislav] Created https://github.com/w3c/webextensions/issues/525
* Please comment as soon as possible if you intend to join us.
* [tomislav] Very exciting! TPAC was very useful. Welcome participation of community members, your involvement at TPAC was invaluable.

[PR 512](https://github.com/w3c/webextensions/pull/512): update bikeshed build to support multiple bikeshed files

* [simeon] Patrick called out in the PR that this should be merged after PR 508.
* [patrick] Yes.

[PR 508](https://github.com/w3c/webextensions/pull/508): create specification for window.browser

* [patrick] Got some review feedback from Rob about window.browser not being read-only; Oliver had a question on browser availability conditional (on externally_connectable). Path forward is to merge as-is, and update the spec in a future PR to clarify that the availability is optional, e.g. comparable to SecureContexts.
* [rob] Does Safari unconditionally expose the browser namespace?
* [timothy] Yes.
* [rob] Chrome exposed chrome.runtime.sendMessage unconditionally for a long time in practice due to the presence of a built-in Chrome extension with externally_connectable, but that became conditional at some point when this was removed. Is the namespace conditional or unconditional in Chrome?
* [patrick] We expose other things like csi and loadTimes on the chrome namespace, so the namespace as a whole is unconditional.
* [patrick] Once merged, we can start the work in Chrome to support the browser namespace.

[Issue 229](https://github.com/w3c/webextensions/issues/229): Extension icons for light/dark/custom theme

* [oliver] (added [comment](https://github.com/w3c/webextensions/issues/229#issuecomment-1877038396) to discussion) Adding light/dark to icons would become a hard error in Chrome. To enable the feature without breaking backwards-compatibility, we proposed a new key (icon_variants) to support light/dark icons.
* [carlos] Suggest focusing on extension API to set icons at runtime, then declaratively through the manifest. Maybe discuss with webapps CG?
* [oliver] Would like to move forward with the current proposal.
* [timothy] Tend to agree. Wouldn't want different media queries to be impossible.

[PR 484](https://github.com/w3c/webextensions/pull/484): Update table with persistence of APIs

* [oliver] Small update to the table.
* [simeon] Just approved it.

[PR 499](https://github.com/w3c/webextensions/pull/499): action.onUserSettingsChanged proposal

* [rob] I added a review requesting clarification on whether the event is supposed to include all properties, or only changed properties.

[PR 370](https://github.com/w3c/webextensions/pull/370): Initial Firefox schemas, 2023Q1

* [oliver] Seems like there were questions about licensing.
* [tomislav] That has been resolved. I will update the PR.

[Issue 336](https://github.com/w3c/webextensions/issues/336): Inconsistency: action.setIcon() & action.setBadgeBackgroundColor()

* [oliver] Has not had the chance to look into this.

[Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR

* [timothy] Universally requested from content blockers. A bit difficult to implement in our current implementation (in Safari), wondering about other browsers.
* [rob] Last time we discussed this, I proposed that we offer the functionality to replace the response (body+head). A previous request about filtering responses ([issue 506](https://github.com/w3c/webextensions/issues/506)) was rejected because of concerns about blocking requests and memory. In this case, my suggestion is declarative, which would not have that concern.
* [timothy] I'll follow up internally.
* [rob] How about Chrome?
* [oliver] Will need to look into this.

[Issue 524](https://github.com/w3c/webextensions/issues/524): Pre-rendering in new tabs and window ID behavior

* [oliver] Chrome is considering prerendering when hovering over a link. Unclear how this should be exposed to extensions.
* [timothy] There is the concept of tabId: null. Could use that here if we don't know where it will be.
* [tomislav] Starting in the existing window and emitting an event to move it would probably be most compatible with current extensions.
* [timothy] That would be the safest option.
* [oliver] Do browsers have any implementation of prerendering like this?
* [timothy] iOS offers preview on long-press. Extensions run in that.
* [rob] Can't make it part of the window because the tab index would be incorrect. That implies that a new synthetic window should be used, followed by moving tabs between windows if needed.
* [timothy] A new hidden window with the prerender as the only child might make sense.
* [timothy] Safari knows what the next ID will be, could be feasible to create a new window and move the tab to the previous window
* [simeon] would it be useful to have a dedicated window ID for prerendering?
* [tomislav] Not necessary, we already have window lifecycle events for most cases. Would be against introducing more magic.

[Issue 460](https://github.com/w3c/webextensions/issues/460): Proposal: declarativeNetRequest: matching based on response headers

* [oliver] There has not been much feedback, and the implementation is complicated. Please offer feedback.
* [rob] I'm going to take a look within a few days.
* [timothy] I'll add a follow-up label for Safari.

[Issue 515](https://github.com/w3c/webextensions/issues/515): sidePanel API: support "one instance per tab" in openPanelOnActionClick

* [timothy] Request to support one instance per tab in sidePanel. SidePanel is Chrome-specific, any opinions on Firefox's end?
* [rob] We have the concept of tab-specific panels/titles in the sidebar_action API in Firefox. I don't know off the top of my head whether the sidebar would close when you switch away from a tab though.
* [timothy] We don't currently support this API, but conceptually the sidebar is outside the hierarchy of current tabs.
* [oliver] I think that it's worth filing an issue in the crbug issue tracker. Should sidePanel be discussed here since it is Chrome-specific?
* [rob] Some aspects are more general to the sidebar_action API, which makes them a good fit for discussion here.
* [timothy] I also think that it's worth discussing them here.
* (due to the lack of time, the remaining sidePanel issues will be skipped in this meeting)

[Issue 518](https://github.com/w3c/webextensions/issues/518): Manifest v3 background scripts should not be killed when there are active listeners

* [simeon] Request here is essentially to request the ability to have persistent:true in MV3 extensions. I chatted with some browser vendors, and there seems to be consensus on supporting longer-running extensions, but in an event-based model without guaranteed persistence.
* [simeon] In this group the runtime.waitUntil method was discussed before in [issue 416](https://github.com/w3c/webextensions/issues/416).
* [timothy] Battery life is important and extensions need to be designed to account for shutdown when they are not running. Am definitely supportive of waitUntil from issue 416.
* [rob] As mentioned in issue 416, Chrome currently has special lifetime-extending triggers in several web platform APIs such as WebSocket, but the set of APIs this applies to is undocumented. On Firefox's side we would prefer to implement runtime.waitUntil over implementing such special cases, because that is easier to comprehend, document and maintain.
* [oliver] On Chrome's side we are supportive of the API, but constraints need to be clarified and enforced.
* [simeon] A benefit of a waitUntil style approach is it gives browsers more insight into the work an extension currently has in flight.
* [timothy] Would like to avoid the situation where developers copy-paste SO answers that devs copy-paste to create long-lived background contexts.
* [alexei] There are already several hacks available in Chrome and Firefox, to trigger events etc to keep the extension running.
* [rob] And this existing ability and actual practice of postponing termination through hacks is why we would prefer a dedicated alternative method. With a dedicated method such as runtime.waitUntil, extension authors don't have to resort to hacks, while browsers can have the ability to implement some degree of control, such as logging or informing users that a task is long-running.
* [tomislav] Want to help developers avoid getting shut down in the middle of a critical task. Do not want to support arbitrary long lived execution. That's the distinction we're trying to draw.
* [timothy] What do we want to do with this issue?
* [rob] If this request boils down to a request to support “persistent:false”, then we should close the issue because the consensus is to not support that. We can refer to waitUntil as the preferred alternative.

[Issue 519](https://github.com/w3c/webextensions/issues/519): Proposal: Event.addListener should accept an interface.

* [rob] Opposed to using handleEvent as it is already used in the web platform with the expectation of receiving an Event instance, whereas extension events are objects. Supportive of taking an object with a callback property under a different name.
* [simeon] Would it be feasible to make it a more webby interface? For example, have extension API namespaces inherit from EventTarget and support .addEventListener(). For example, browser.webRequest.addEventListener(‘onBeforeRequest', () => {}).
* [timothy] Would be supportive of this. We used to support a more webby API with event bubbling, etc.
* (ran out of time, this discussion was cut short)

The next meeting will be on [Thursday, February 1st, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=65badf00,3c0)
6 changes: 4 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,22 +10,24 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2024-01-18 at 8 AM PST = https://everytimezone.com/?t=65a86a00,3c0
- 2024-02-01 at 8 AM PST = https://everytimezone.com/?t=65badf00,3c0
- 2024-02-15 at 8 AM PST = https://everytimezone.com/?t=65cd5400,3c0
- 2024-03-18 until 2024-03-21, in-person meeting ([issue 525](https://github.com/w3c/webextensions/issues/525))

## Past meetings

* 2024-01-18 ([minutes](2024-01-18-wecg.md))
* 2024-01-04 ([minutes](2024-01-04-wecg.md))
* 2023-12-07 ([minutes](2023-12-07-wecg.md))
* 2023-11-23 ([minutes](2023-11-23-wecg.md))
* 2023-11-09 ([minutes](2023-11-09-wecg.md))
* 2023-10-26 ([minutes](2023-10-26-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2024**

* 2024-01-18 ([minutes](2024-01-18-wecg.md))
* 2024-01-04 ([minutes](2024-01-04-wecg.md))

**2023**
Expand Down