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-05-23 meeting #620

Merged
merged 1 commit into from
Jun 3, 2024
Merged

Publish minutes of 2024-05-23 meeting #620

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

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=664e8700,384
Call-in details: [WebExtensions CG, 23rd May 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240523T080000/)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


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

The meeting will start at 3 minutes after the hour.

See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format.

* **Announcements** (2 minutes)
* **Triage** (15 minutes)
* [Issue 610](https://github.com/w3c/webextensions/issues/610): [DNR] main_frame redirect to an extension page + accessing the original URL and POST data
* [Issue 611](https://github.com/w3c/webextensions/issues/611): Expose chrome.runtime.inIncognitoContext
* [Issue 612](https://github.com/w3c/webextensions/issues/612): Expose openOrClosedShadowRoot for userscripts
* [Issue 615](https://github.com/w3c/webextensions/issues/615): userstyles support
* [Issue 617](https://github.com/w3c/webextensions/issues/617): manifest key to enable automatic injection of content scripts after installation/update
* [Issue 619](https://github.com/w3c/webextensions/issues/619): Proposal: Add alias for tabs permission
* **Timely issues** (10 minutes)
* [PR 613](https://github.com/w3c/webextensions/pull/613): Valid json and consistent use of color_scheme
* [PR 614](https://github.com/w3c/webextensions/pull/614): Use a plural array type like "permissions" for simplicity
* [Issue 414](https://github.com/w3c/webextensions/issues/414#issuecomment-2091905159): Specifying css origin as USER in declarative/registered content scripts
* **Check-in on existing issues** (20 minutes)
* [PR 546](https://github.com/w3c/webextensions/pull/546): update window.browser spec
* [PR 569](https://github.com/w3c/webextensions/pull/569): Add getOSLanguage proposal
* [Issue 231](https://github.com/w3c/webextensions/issues/231): Extension API to find the public suffix (eTLD) of a given URL/domain


## Attendees (sign yourself in)

1. Timothy Hatcher (Apple)
2. Oliver Dunk (Google)
3. Jarek Samic (1Password)
4. Carlos Jeurissen (Jeurissen Apps)
5. Rob Wu (Mozilla)
6. Solomon Kinard
7. Hilary Hacksel
8. Richard Worth (Capital One)
9. Simeon Vincent (Mozilla)
10. Tim Heflin (Keeper)
11. Mike Selander (1Password)
12. Alisa Tikhova (eyeo)
13. David Johnson (Apple)
14. Mukul Purohit (Microsoft)
15. Tomislav Jovanovic (Mozilla)


## Meeting notes

[Issue 610](https://github.com/w3c/webextensions/issues/610): [DNR] main_frame redirect to an extension page + accessing the original URL and POST data

* [timothy] We've seen requests like this on the Safari side as well. PDF.js use case. Accessing the URL looks useful. POST data seems useful.
* [oliver] PDF use case could be covered by the header matching proposal.
* https://github.com/w3c/webextensions/issues/460
* [rob] PDF viewer use case is not fully addressed by #460. The way current extensions work is that they redirect the request to an extension document and issue the request again. Better solution would be to allow the extension to receive the original stream of data.
* [oliver] Would love to have a way to let an extension replace the built-in PDF viewer.
* [timothy] Seems preferable. Keeps original URL in browser chrome.
* [rob] Quick remark: this issue is a follow-up to a previous request that aimed to make this possible without web_accessible_resources. The new proposal does still not eliminate the need for web_accessible_resources, because web pages can still reference the frame/document containing the post-redirect extension document and use postMessage.

[Issue 611](https://github.com/w3c/webextensions/issues/611): Expose chrome.runtime.inIncognitoContext

* [timothy] Goal is to expose it in all contexts and then deprecate original chrome.extension.inIncognitoContext. Not sure about the goal.
* [rob] Goal of reporter is to request it to be exposed to user scripts.
* [rob] I see two separate requests: move this to runtime and exposing to user scripts. I'm supportive of moving this to the runtime namespace. We should be careful with exposing more data to user scripts in general, but I don't have strong opinions about this specific request.
* [timothy] Also supportive of moving it. We don't support userScripts, so no strong opinions.
* [oliver] What are the use cases?
* [rob] User script managers have a getInfo method that exposes this. Suspect it may allow user scripts to avoid saving data.
* [oliver] I don't have much contexts, would have to follow-up.

[Issue 612](https://github.com/w3c/webextensions/issues/612): Expose openOrClosedShadowRoot for userscripts

* [rob] Again requesting more functionality for user scripts. Unclear if we should expose it on the current namespace or directly on the DOM. Firefox has modified the element prototype in the past.
* [timothy] I see the appeal of exposing it on Elements instead of duplicating it in the dom.
* [rob] Are you in favor in exposing it on Element.prototype?
* [oliver] I'd like to follow up, we'd likely be more receptive to exposing the dom namespace since we already have that.
* [simeon] I'm hesitant about exposing this kind of functionality directly on the DOM. For the moment it seems safer to keep extension-specific capabilities on extension namespaces.
* [rob] This and earlier requests ([issue 611](https://github.com/w3c/webextensions/issues/611), [issue 612](https://github.com/w3c/webextensions/issues/612)) are about exposing functionality that already exist in content scripts to the user script world. Although the issue specifically includes the desire to avoid spawning another world, I'd prefer doing that than adding many APIs to cater a few extensions, and then using synchronous communication between worlds.
* [oliver] Can't do this with the current API – can't pass an element reference between user script and isolated world.
* [rob] Not with the current APIs, but in discussions around synchronous messaging, I explicitly called out the desire to support passing element references.
* (see “User Scripts” at [2024-03-20-san-diego-meetup.md](https://github.com/w3c/webextensions/blob/main/_minutes/2024-03-20-san-diego-meetup.md))

[Issue 615](https://github.com/w3c/webextensions/issues/615): userstyles support

* [timothy] Requesting . Unfortunate that we're duplicating functionality.
* [oliver] Requested before, [issue 489](https://github.com/w3c/webextensions/issues/489).
* [oliver] Seemingly reasonable, but have to take a closer.
* [rob] Let's revisit this later when everyone has had a chance to evaluate this request.

[Issue 617](https://github.com/w3c/webextensions/issues/617): manifest key to enable automatic injection of content scripts after installation/update

* [timothy] Currently Safari and Firefox's default behavior.
* [oliver] How do you handle enabling/disabling multiple times?
* [rob] Content script sandbox is destroyed on disable. The content script is removed. Any modifications remain.
* [timothy] Similarly in Safari, the isolated world goes away.
* [oliver] Do you experience any issues? E.g. global.
* [tomislav] Globals don't collide because the JS environment was removed.
* [rob] In Chrome when an extension is disabled extension bindings are disabled, so accessing extension APIs throws.
* [rob] Anecdotally, I have frequently seen extensions that query all tabs and inject a script. I see Carlos nodding, so he is also one of these developers.
* [simeon] I'm not 100% certain, but I think one of the reasons that Chrome doesn't inject content scripts at install is that document_start scripts cannot be injected at the expected page lifecycle phase.
* [timothy] We communicate with developers that they should anticipate being run after the run_at state. It is a very common occurrence in Safari because scripts are injected on demand.
* [simeon] In the case of an extension that is set to run-on-click in Chrome, there is an explicit signal. If a script is declared at document_start, Chrome will say that the page needs to be reloaded for the script to apply.
* [rob] On Firefox's side we are supportive.
* [timothy] We are supportive on Safari's side.
* [tomislav] In Firefox we wouldn't change the default behavior though.
* [rob] In Firefox and Safari it would be opt-out, in Chrome probably opt-in.
* [timothy] Exactly.
* [oliver] Open to discussing the idea, but not something we'd implement soon.
* [rob] Would you take patches?
* [oliver] I'd have to follow up.

[Issue 619](https://github.com/w3c/webextensions/issues/619): Proposal: Add alias for tabs permission

* [oliver] tabs is one of the most commonly used APIs, but also a “tabs” permission. Many new developers are probably unaware that this permission is not needed for the tabs API. We cannot remove the tabs permission yet, but introducing a new alias would enable us to eventually deprecate the “tabs” permission in favor of an alternative.
* [timothy] Supportive of an alias. Note that in Safari, the “tabs” permission does not expose url, title, faviconUrl unless host permissions have also been granted.
* [simeon] Other APIs uses period-delimited permission names.
* [timothy] Usually used for methods, but that is not the case here.
* [rob] The tabs.Tab type is also visible in other APIs, not just the tab.
* [timothy] True.
* [rob] No strong opinions on naming yet. I support the capability request here.

[PR 613](https://github.com/w3c/webextensions/pull/613): Valid json and consistent use of color_scheme

* [timothy] I've approved; updated JSON syntax to be valid and making color_scheme plural, and always requiring an array.
* [simeon] In cases like this, where everyone agrees/approves, should we leave it to the author to merge, or the last approver?
* [rob] I'd say last approver, since not every author can merge.
* [mukul] Merged.

[PR 614](https://github.com/w3c/webextensions/pull/614): Use a plural array type like "permissions" for simplicity

* [timothy] Discussed before with PR 613.

[Issue 414](https://github.com/w3c/webextensions/issues/414#issuecomment-2091905159): Specifying css origin as USER in declarative/registered content scripts

* [timothy] Safari Tech Preview this issue. My fix added css origin to the manifest, historically it had only been in the insertCSS function.
* [oliver]
* [rob] Supportive - this is a flag that we internally support for insertCSS, but aren't forwarding it.
* [rob] Spelling?
* [timothy] snake_case for the property name, lower case for the values in the manifest. In the API (registerContentScripts) the value is case-insensitive.
* [oliver] Are you planning to document this on MDN?
* [timothy] I have created a task to do so.
* [rob] Would Chrome also be willing to adopt it, and if so, what spelling?
* [oliver] I assume that we'd go with Safari's behavior.
* [rob] The property names, and lowercase manifest seems reasonable. Accepting multiple cases is new to the extension API surface and I expect some discussions there first.
* [timothy] Looks like our manifest value parsing is also case-insensitive.
* [timothy] There was also a previous issue about inconsistencies in case-sensitiveness.

[PR 546](https://github.com/w3c/webextensions/pull/546): update window.browser spec

* [timothy] Any blockers?
* [rob] I have exchanged mails with Patrick about this, specifically on whether browser and chrome should be identical objects, or whether they should be distinct objects with the same properties.

[PR 569](https://github.com/w3c/webextensions/pull/569): Add getOSLanguage proposal

* _The pull request has been renamed to “[PR 569](https://github.com/w3c/webextensions/pull/569): Add i18n-system-languages proposal”._
* [carlos] Updated PR. Renamed getOSLanguage to getSystemUILanguage. Introduced getPreferredSystemLanguages method, name is suggested to align with Electron.
* [rob] Last time we skipped this topic because you intended to reach out to the Internationalization group. Did you get a response?
* [carlos] Still awaiting response. They discussed it but the notes are not public.
* [timothy] Supportive and willing to implement in Safari.
* [simeon] I don't see discussions on the name of getPreferredSystemLanguages.
* [carlos] This was discussed in [issue 252](https://github.com/w3c/webextensions/issues/252). There are two different use cases for getting a single language or a list of it.
* [timothy] Difference with getAcceptedLanguages?
* [carlos] Not different in Safari, but in other browsers this value can be customized in the browser.

[Issue 231](https://github.com/w3c/webextensions/issues/231): Extension API to find the public suffix (eTLD) of a given URL/domain

* [oliver] I met with Simon Friedberger from Mozilla and Simone Carletti, both PSL maintainers. Generally very supportive and would like to see this API. Only concern is not the volume but the quality of it. They would appreciate any education we can provide for developers. On Mozilla's side, are you interested in sponsoring this feature?
* [tomislav] We have a contributor who shared a patch. We can check if they are interested in submitting a proposal.
* [rob] Would Google be supportive of this API?
* [oliver] Supportive of the API, but probably not implementing soon.
* [timothy] Supportive of the idea.

The next meeting will be on [Thursday, June 6th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6660fc00,384)
8 changes: 4 additions & 4 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,26 +10,26 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2024-05-09 at 8 AM PDT = https://everytimezone.com/?t=663c1200,384
- 2024-05-23 at 8 AM PDT = https://everytimezone.com/?t=664e8700,384

- 2024-06-06 at 8 AM PDT = https://everytimezone.com/?t=6660fc00,384
- 2024-06-20 at 8 AM PDT = https://everytimezone.com/?t=66737100,384

## Past meetings

* 2024-05-23 ([minutes](2024-05-23-wecg.md))
* 2024-05-09 ([minutes](2024-05-09-wecg.md))
* 2024-04-25 ([minutes](2024-04-25-wecg.md))
* 2024-04-11 ([minutes](2024-04-11-wecg.md))
* 2024-03-28 ([minutes](2024-03-28-wecg.md))
* 2024-03-20 meetup at San Diego ([minutes](2024-03-20-san-diego-meetup.md))
* 2024-03-19 meetup at San Diego ([minutes](2024-03-19-san-diego-meetup.md))
* 2024-03-18 meetup at San Diego ([minutes](2024-03-18-san-diego-meetup.md))
* 2024-03-14 ([minutes](2024-03-14-wecg.md))

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

**2024**

* 2024-05-23 ([minutes](2024-05-23-wecg.md))
* 2024-05-09 ([minutes](2024-05-09-wecg.md))
* 2024-04-25 ([minutes](2024-04-25-wecg.md))
* 2024-04-11 ([minutes](2024-04-11-wecg.md))
Expand Down