-
Notifications
You must be signed in to change notification settings - Fork 54
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2024-09-29 meeting
- Loading branch information
Showing
2 changed files
with
177 additions
and
1 deletion.
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,175 @@ | ||
| # WECG Meetings 2024, Public Notes, Aug 29 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=66cfba00,384 | ||
| Call-in details: [WebExtensions CG, 29th August 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240829T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #672](https://github.com/w3c/webextensions/issues/672), [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 673](https://github.com/w3c/webextensions/issues/673): Use match_origin_as_fallback behavior by default in scripting.executeScript | ||
| * [Issue 677](https://github.com/w3c/webextensions/issues/677): Inconsistent Navigation History Behavior Across Browsers with Resource URLs Using tabs.update() | ||
| * [Issue 680](https://github.com/w3c/webextensions/issues/680): Extensions API to query the current browser theme | ||
| * **Timely issues** (15 minutes) | ||
| * [PR 581](https://github.com/w3c/webextensions/pull/581): Add crossSiteAncestor value to partitionKey in cookies API | ||
| * [PR 675](https://github.com/w3c/webextensions/pull/675): Add developer tools contexts in runtime.getContexts() proposal | ||
| * [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() | ||
| * [PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() | ||
| * **Check-in on existing issues** (15 minutes) | ||
| * [Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024 | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Solomon Kinard (Google) | ||
| 3. Giorgio Maone (Tor, NoScript) | ||
| 4. David Johnson (Apple) | ||
| 5. Kiara Rose (Apple) | ||
| 6. Oliver Dunk (Google) | ||
| 7. Mukul Purohit (Microsoft) | ||
| 8. Carlos Jeurissen (Jeurissen Apps) | ||
| 9. Aaron Selya (Google) | ||
| 10. Simeon Vincent (Mozilla) | ||
| 11. Maxim Topciu (AdGuard) | ||
| 12. Tim Heflin (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 673](https://github.com/w3c/webextensions/issues/673): Use match_origin_as_fallback behavior by default in scripting.executeScript | ||
|
|
||
| * [oliver] In MV2, matchAboutBlank was not the default for tabs.executeScript; in MV3 scripting.executeScript defaults to true, because the parameters were already very specific to where to execute. So by default it injects in the specific frame. Later we introduced matchOriginAsFallback, but because it happened after scripting.executeScript, it is not the default. Toph suggested that it should perhaps be a new option. We at Chromium are leaning towards true by default. | ||
| * [rob] Sounds reasonable. In Firefox it defaults to true. Note that this is about scripting.executeScript (which does not even have an option to set it to false); in scripting.registerContentScripts it defaults to false and can be customized. | ||
| * [oliver] This makes sense - I think that these cases are also different; in the manifest registration the patterns are declared, whereas executeScript is targeted. | ||
| * [timothy] Agreed. | ||
| * [rob] tophf asked about opting out. | ||
| * [oliver] Can't think of a strong use case off the top of my head. | ||
| * [timothy] I don't think that there needs to be a way to opt out. | ||
| * [rob] Does Safari support matchOriginAsFallback? | ||
| * [timothy] Not yet. Something I hope to add soon. | ||
| * [rob] Sounds like we can declare the support status as “chrome:supportive”, “firefox:implemented”, “safari:supportive”. | ||
| * [oliver] Does Safari already run scripts despite not recognizing “matchOriginAsFallback”? In that case it can declare implemented. | ||
| * [kiara] I will check. | ||
|
|
||
| [Issue 677](https://github.com/w3c/webextensions/issues/677): Inconsistent Navigation History Behavior Across Browsers with Resource URLs Using tabs.update() | ||
|
|
||
| * [simeon] tabs.update preserves history in Firefox; in Chrome removes history if the user has not interacted with history; Safari erases all previous history items. | ||
| * [timothy] Surprising that we lose the history. I know that we swap history when navigating to an extension page. Sounds like a bug to me, definitely not intentional. It is intentional to not show the actual extension URL (UUID). | ||
| * [simeon] What is shown in Safari? | ||
| * [timothy] A blank field. | ||
| * [rob] Not even an extension name or something? | ||
| * [timothy] If you have the tab title on you see the tab title in the relevant location. | ||
| * [rob] From the point of origin identification this is surprising, but back to the original issue… | ||
| * [simeon] Chromium folks, thoughts on history intervention here? | ||
| * [oliver] Reluctant to remove this behavior entirely. There are use cases that want to replace history entirely. There are alternatives such as redirecting. | ||
| * [timothy] Did we not talk about an option to customize this behavior? | ||
| * [rob] [Issue 664](https://github.com/w3c/webextensions/issues/664): Proposal: Support loadReplace for tabs.update() | ||
| * [oliver] Would implementing 664 be sufficient? | ||
| * [simeon] Probably yes, once Safari fixes their bug. | ||
| * [rob] Firefox default is to preserve history. The suggested loadReplace would be boolean. If true, it replaces previous. | ||
| * [simeon] If a developer explicitly set loadReplace to false, would Chrome not collapse history? | ||
| * [oliver] I can see it going either way. | ||
| * [rob] I think that it would make sense to keep as much of the history as possible, and only overwrite the current history entry when loadReplace:true. | ||
| * [timothy] I'm inclined to also add to the history, and have an option to replace the last (loadReplace:true). | ||
| * [rob] Oliver, could you check with Chrome engineering what their preference is? | ||
| * [oliver] I'll check with the team. | ||
| * [rob] Rule of thumb: tabs.update simulates the user navigating to the specified URL. | ||
|
|
||
| [Issue 680](https://github.com/w3c/webextensions/issues/680): Extensions API to query the current browser theme | ||
|
|
||
| * [simeon] Short summary, is extensions cannot tightly integrate in the browser theme; Firefox has a theme API namespace that can be used to query the theme, but it does not return info for the default theme. | ||
| * [timothy] I recall discussing this a while back. I think we considered CSS variables for this, and that would be my preference here. | ||
| * [rob] CSS variables would also be my preference for this. | ||
| * [timothy] Complication is that Safari webview's background defaults to transparent, and that would bleed through to the popup underneath. Most extension override the background, … | ||
| * [rob] @fregante noted the existence of system colors such as Canvas and CanvasText. This is a standard and should be used if needed. Would like to know what other colors developers feel are missing. | ||
| * [timothy] My long-winded thought on the popup background is that CSS variables may sometimes not be enough. Explicit variables for extensions would be ideal, but system colors seem like a good general solution. | ||
| * [rob] Could you elaborate on what you described in the issue, with screenshots? | ||
| * [timothy] Will do. | ||
| * [mukul] Chrome's position? | ||
| * [oliver] Not sure; I think that Patrick worked on this before, I will check. | ||
| * [mukul] FYI: this issue was filed by a colleague of mine. Rob, what colors were you mentioning? | ||
| * [rob] System colors should match the current default theme, e.g. dark theme. Would like to know if there are colors that are missing from the default set of colors. | ||
|
|
||
| [PR 581](https://github.com/w3c/webextensions/pull/581): Add crossSiteAncestor value to partitionKey in cookies API | ||
|
|
||
| * [aaron] We're mostly there; Rob and I have been going back and forth on hammering out a new API part of this change, which would allow extensions to query the partitionKey for a given frame so they can query the partitionKey instead of guessing one. Seem to be in alignment on overall PR features. | ||
| * [rob] We are aligned on the capability; I have to review the most recent changes to the proposal. I also raised this with [bvandersloot](https://github.com/bvandersloot-mozilla) at Mozilla who also participates in the Privacy CG, and the API also looks generally fine to him. | ||
| * [aaron] Started the implementation in Chromium. Should have it working in the next week. Have started receiving breakage reports from ancestor changes in Chromium, increasing the priority of the issue. | ||
| * [rob] Do you expect this to ship before TPAC? Would like to discuss it in person if possible. | ||
| * [aaron] Expect to get LGTMs in the next week or so. Whether or not we merge is not firm. Would not expect it to land before M129. In M130 at the latest, which would be around or slightly before TPAC. This is for everything besides the new API – adding a property to the partitionKey, not the API to query the partition key. | ||
| * [rob] On Firefox side I also saw a PR to expand the cookies extension API. This also covers the new property only, the getPartitionKey method is not included yet. I think these can land separately. | ||
| * [aaron] Separating them make sense to me. | ||
| * [rob] From the extension developer POV it would be ideal if they could land in the same release, but not a blocker. | ||
| * [aaron] Goal of being in alignment by or having final conversations at TPAC sounds good. | ||
| * [rob] Any input from Safari's side? | ||
| * [timothy] We'll look at this at some point, but don't have an implementation yet. | ||
|
|
||
| [PR 675](https://github.com/w3c/webextensions/pull/675): Add developer tools contexts in runtime.getContexts() proposal | ||
|
|
||
| * [mukul] Got feedback from Devlin and Oliver; more feedback is welcome. | ||
| * [rob] Non-browser windows are usually not exposed in the extension window. | ||
| * [simeon] My thought as well, windowId is -1? | ||
| * [mukul] Can set to -1. | ||
| * [oliver] tabId and frameId were also part of the discussion. | ||
| * [simeon] Devtools pages can still have sub-frames. How would a developer target a sub-frame in a devtools panel? | ||
| * [rob] FrameId is usually only meaningful if tabId is set. In Chrome/Firefox It's globally unique. In theory it could also be useful without a tabId, but there isn't precedent for it. Not necessarily opposed to changing that to support targeting sub-frames. | ||
| * [timothy] Correct. tabId is usually required with frameId. We have an issue where frameId can be non-unique, but we are trying to figure that out. Supportive of frameId -1. | ||
| * [aaron] In Chrome frameId is only unique within a tab. | ||
| * [simeon] Would documentId make sense here? | ||
| * [oliver] From my side, the main justification for exposing some of these is to get some context about where it is open. The more I think about it - it is not always set. frameId -1 makes sense. For documentId there is not really a benefit yet. | ||
| * [timothy] I thought that the API returns information about contexts, and that is why documentId could be useful. | ||
| * [simeon] It seems to be useful when using getContext() to know what tab context is being debugged. | ||
| * [carlos] For that devtools.inspectedWindow can be used. | ||
| * [simeon] Downside is it's an additional round trip. | ||
| * [rob] When a context is associated with a tabId, a developer could reasonably expect to be able to interact with that context through the tabId. But e.g. sendMessage cannot reach the devtools. | ||
| * [oliver] I think that what Simeon was saying is that it could be exposed as something different | ||
| * [rob] I think that documentId should be set, since the devtools panel is a document. | ||
| * [mukul] The proposal references an issue ([issue 670](https://github.com/w3c/webextensions/issues/670)) that already emphasizes that documentId should be available. | ||
| * [simeon] Apparently we already discussed and agreed that documentId should be set. | ||
| * [oliver] So to recap: tabId, frameId, windowId all -1, documentId set. | ||
| * [timothy] When non-docked -1, when docked the actual window could make sense. | ||
| * [rob] Not opposed to making it not -1 when docked. Fine either way. | ||
| * [oliver] No preference. Proposal mentions -1 everywhere. I can ask Devlin if there is a desire to include other values. | ||
| * [timothy] -1 when not docked, actual windowId when docked. | ||
|
|
||
| [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() | ||
|
|
||
| * [simeon] Devlin and Rob worked together on this proposal to execute code in different worlds. Rob, do you have more context? | ||
| * [rob] I need to review this proposal. It's a follow-up to discussions in San Diego. | ||
| * Meeting notes: [2024-03-20-san-diego-meetup.md](_minutes/2024-03-20-san-diego-meetup.md) | ||
| * [simeon] This PR was opened in the past week. Is there any additional discussion needed? | ||
| * [rob] I think that review before discussion would make sense. | ||
| * [simeon] The proposal proposes JSON serialization. Would transferables make more sense? | ||
| * [rob] Structured cloning you mean? Definitely. | ||
| * [rob] Would like to encourage extension devs to review and chime in. Especially if you have use cases that would be enabled by these methods. | ||
|
|
||
| [PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() | ||
|
|
||
| * [simeon] Communication between different worlds. | ||
| * [rob] I still need to review this PR. | ||
| * [simeon] Oliver, do you have additional context? | ||
| * [oliver] I don't have additional context. Similar to the previous PR, this came from discussions in San Diego. | ||
| * [simeon] I don't see mentions of synchronous messaging. Wondering if it is sync of async. | ||
| * [oliver] Should be defined. | ||
| * [rob] Synchronous would be preferred, because the current primitives (that can be intercepted by web pages) are already synchronous. | ||
| * [timothy] That's also what I recall. One aspect I find odd is that you have to specify a world when creating a port. The script can already decide where to send the port to. | ||
|
|
||
| [Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024 | ||
|
|
||
| * [simeon] Request for more topics - the issue already has postMessage, declarative cosmetic rules, is there anything else that you'd like to see discussed or talked about? | ||
| * [timothy] Devlin's createPort proposal addresses my first topic. | ||
| * [simeon] Next meeting is the last public meeting before TPAC. | ||
| * [timothy] Should we cancel the regular meeting that happens during TPAC? | ||
| * [rob] In the last TPAC events we continued the regular session. | ||
|
|
||
| The next meeting will be on [Thursday, September 12th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=66e22f00,384) |
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