-
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 branch 'main' into proposals-tabs-query-filter-document-id
- Loading branch information
Showing
2 changed files
with
189 additions
and
2 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,185 @@ | ||
| # WECG Meetings 2024, Public Notes, Mar 28 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=6604b300,384 | ||
| Call-in details: [WebExtensions CG, 28th March 2024](https://www.w3.org/events/meetings/df93a5ff-d117-44c0-bc3e-d2a31d1c196d/) | ||
| Zoom issues? Ping `@robwu` (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #567](https://github.com/w3c/webextensions/issues/567), [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 568](https://github.com/w3c/webextensions/issues/568): Proposal: add commands.OnCommandData similar to menus.OnClickData | ||
| * [Issue 570](https://github.com/w3c/webextensions/issues/570): Inconsistency: dns.resolve() | ||
| * [Issue 573](https://github.com/w3c/webextensions/issues/573): Inconsistency: proxy API | ||
| * [Issue 574](https://github.com/w3c/webextensions/issues/574): Proposal: Add a dedicated CSP API for web extensions | ||
| * [Issue 575](https://github.com/w3c/webextensions/issues/575): Inconsistency: match_about_blank | ||
| * **Timely issues** (10 minutes) | ||
| * [PR 569](https://github.com/w3c/webextensions/pull/569): Add getOSLanguage proposal | ||
| * [PR 576](https://github.com/w3c/webextensions/pull/576): Add guidance on the review expectations of proposals | ||
| * [PR 577](https://github.com/w3c/webextensions/pull/577): Add references to proposing API changes in CONTRIBUTING.md | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [Issue 545](https://github.com/w3c/webextensions/issues/545): Proposal: Change keyword for the Omnibox API. | ||
| * [PR 532](https://github.com/w3c/webextensions/pull/546): update window.browser spec | ||
| * [PR 560](https://github.com/w3c/webextensions/pull/560): Proposal: Multiple user script worlds | ||
| * [Issue 162](https://github.com/w3c/webextensions/issues/162): Declarative Net Request proposal: disable individual static rules | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Timothy Hatcher (Apple) | ||
| 3. Andrey Meshkov (AdGuard) | ||
| 4. Oliver Dunk (Google) | ||
| 5. Jarek Samic (1Password) | ||
| 6. Giorgio Maone (NoScript, Tor) | ||
| 7. Simeon Vincent (Mozilla) | ||
| 8. Richard Worth (Capital One) | ||
| 9. Mukul Purohit (Microsoft) | ||
| 10. Maxim Topciu (AdGuard) | ||
| 11. Carlos Jeurissen (Jeurissen Apps) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| In-person meeting | ||
|
|
||
| * [timothy] We had an in-person meeting last week, which was very productive. | ||
| * [rob] We have about 70 pages of meeting notes, I'll publish them once the participants have consented to publishing them. Subscribe to [issue 525](https://github.com/w3c/webextensions/issues/525) for updates. | ||
|
|
||
| [Issue 568](https://github.com/w3c/webextensions/issues/568): Proposal: add commands.OnCommandData similar to menus.OnClickData | ||
|
|
||
| * [timothy] Request here is to add details such as frame information when a shortcut is triggered. | ||
| * [oliver] More concrete data about the use case would be useful. | ||
| * [rob] Issue already mentioned use case, e.g. inputting selection data-derived information in an input element, which could be in an iframe. | ||
| * [timothy] Providing additional data such as which frame is focused should be possible. | ||
| * [rob] frameId is already part of the info provided by the context menu. | ||
| * [timothy] This is for commands. | ||
| * [rob] I see. commands.onCommand does not have the information yet. Open to improving this. Does Safari implement the commands API? | ||
| * [timothy] Yes. | ||
| * [rob] Would an API to get the active frame be more useful in general? | ||
| * [timothy] Seems useful. | ||
| * [rob] Potential race condition where focus changes between shortcut invocation and calling a “getFrame” method. In theory a browser can avoid the race condition by recording the active frame along with the onCommand event. | ||
| * [timothy] I can see the value in providing the data in that callback. | ||
| * [rob] Another advantage of an event over a method is that we could have some activeTab behavior for that iframe. | ||
| * [oliver] How would activeTab work with the iframe? The user may trigger a shortcut in an iframe with an unknown origin, distinct from the top-level tab. | ||
| * [rob] That is true. There is currently no precedent, although there have been feature requests for activating activeTab in an iframe with contextMenus.onClicked (https://bugzilla.mozilla.org/show_bug.cgi?id=1838753 / https://issues.chromium.org/issues/40432579 ). | ||
|
|
||
| [Issue 570](https://github.com/w3c/webextensions/issues/570): Inconsistency: dns.resolve() | ||
|
|
||
| * [andrey] Rob, last week you mentioned you had thoughts on how to handle the interface differences. | ||
| * [rob] Property names are not conflicting in Chrome's implementation. They could support Firefox's API. Can you clarify what specific features (API options) you need? Feedback will be useful for Chrome. | ||
| * [andrey] Will do. | ||
| * [oliver] Security is still the major consideration on our side. | ||
| * [timothy] We don't support the API currently; we may potentially adopt it later once you've resolved the inconsistencies. | ||
|
|
||
| [Issue 573](https://github.com/w3c/webextensions/issues/573): Inconsistency: proxy API | ||
|
|
||
| * [timothy] Chrome and Firefox have different sets of capabilities. | ||
| * [andrey] Commenter mentioned some other relevant issues. I'm a bit confused here, I thought that it was Firefox-specific but there is also Chrome stuff there. | ||
| * [oliver] Bypass list and inclusion list are completely different. | ||
| * [andrey] Right, completely different features. Separate feature request to be filed later. | ||
| * [rob] Once the in-person meeting notes are published this issue will probably make more sense to readers. | ||
|
|
||
| [Issue 574](https://github.com/w3c/webextensions/issues/574): Proposal: Add a dedicated CSP API for web extensions | ||
|
|
||
| * [timothy] … Also have a listener to know when the CSP changes. Agreed we need something like this, but not sure this API is the right solution. I'm currently neutral on this. | ||
| * [rob] Can't set CSP per-frame. Only changes to CSP that are possible are making it more strict. Not sure the request takes that into account. | ||
| * [timothy] Implicit request is to be able to relax. | ||
| * [giorgio] From the example in the issue, I think that they want to relax it. | ||
| * [timothy] We will likely need to discuss whether it's even possible to relax. | ||
| * [rob] Are browsers on board with being able to relax a page's CSP? | ||
| * [timothy] I think we need a way, yes. | ||
| * [andrey] There was a proposal by Carlos about being able to change header values. Mostly addresses this. | ||
| * [rob] Only applies to HTTP requests, not non-http requests and meta tags. | ||
| * [simeon] I'm hesitant about relaxing, but I'm supportive of allowing extensions to inject their own assets or embed pages in extension contexts. | ||
| * [andrey] Would like to inject scripts exempt from CSP. | ||
| * [rob] If there's a way to achieve developer goals without relaxing CSP, that would be highly preferable. | ||
| * [andrey] Main problem is that we can't execute main world scripts. | ||
| * [rob] At the in-person meeting, we discussed an API to allow extensions to synchronously execute main world script. Would that address your needs? | ||
| * [andrey] Yes. | ||
|
|
||
| [Issue 575](https://github.com/w3c/webextensions/issues/575): Inconsistency: match_about_blank | ||
|
|
||
| * [timothy] javascript:false, about:srcdoc - should content scripts run here? IMO it should count as about:blank | ||
| * [oliver] Sound reasonable, but I don't have much background here. Rob? | ||
| * [rob] I originally implemented match_about_blank in Chrome for some specific cases of about:blank. With the introduction of sandboxed documents, there was a need for a new version of this capability, which is where match_origin_as_fallback comes from. The intent is that this allows extensions to match any origin. IMO any document scriptable by web content should be scriptable by extensions that use match_origin_as_fallback. | ||
| * [timothy] match_about_blank would primarily be about backwards compatibility. I agree that the new match_origin_as_fallback should match in all cases. | ||
| * [oliver] We should not change match_about_blank to cover cases it doesn't already. | ||
| * [simeon] match_about_blank shouldn't match in this case. We created match_origin_as_fallback to cover cases where the old approach was insufficient. We shouldn't change the behavior of match_about_blank. | ||
| * [rob] Agreed. Firefox will implement match_origin_as_fallback soon. | ||
| * [timothy] Yes, when we implement match_about_blank we will implement the other as well. | ||
| * [rob] FYI you don't need to implement both; the use cases of match_about_blank are covered by match_origin_as_fallback. | ||
| * [timothy] Still want to implement both for broader compatibility. | ||
|
|
||
| [PR 569](https://github.com/w3c/webextensions/pull/569): Add getOSLanguage proposal | ||
|
|
||
| * [rob] This proposal doesn't follow the new process. One of the aspects of the new process template is that there should be at least one browser committing to implementing the API. | ||
| * [timothy] You can count Safari as an implementer. | ||
| * [oliver] I noticed there's only one reviewer. We can add Devlin for Google. | ||
| * [timothy] Right. Process is to have at least one reviewer per browser vendor. | ||
| * [oliver] Is everyone okay with this being synchronous? | ||
| * [timothy] I am. It's already available in the process in Safari. | ||
| * [rob] Even if we don't already have this data, I don't have hesitations about exposing this. | ||
|
|
||
| [PR 576](https://github.com/w3c/webextensions/pull/576): Add guidance on the review expectations of proposals | ||
|
|
||
| * [timothy] Proposal from Devlin to basically describe what we discussed at the in-person meeting. | ||
| * [rob] We should all review it, it can probably be merged soon. | ||
| * [timothy] I approved it this morning. Others should take a look. | ||
|
|
||
| [PR 577](https://github.com/w3c/webextensions/pull/577): Add references to proposing API changes in CONTRIBUTING.md | ||
|
|
||
| * [timothy] Just updated the contributing guide to reference the new process. I've already reviewed and approved. | ||
| * [rob] Looks good to merge. | ||
|
|
||
| [Issue 545](https://github.com/w3c/webextensions/issues/545): Proposal: Change keyword for the Omnibox API. | ||
|
|
||
| * [timothy] Request is to change the keyword at runtime. I am supportive. | ||
| * [simeon] Particularly important to enable conflict resolution with other extensions or even user-defined keywords. There needs to be a way to resolve this conflict. Would be welcome for extensions to allow users to change it. | ||
| * [rob] From an API perspective, I think it would be nice to be able to statically determine what options are available. Second question, should this be an API or should browsers implement this in their own UI? | ||
| * [timothy] I don't think that extensions can do conflict resolution since extensions don't have the full big picture to identify conflicts. Also in favor of browser-defined UI. | ||
| * [rob] How large is this issue? | ||
| * [timothy] I don't know. We don't implement the omnibox UI yet. | ||
| * [oliver] I see a benefit outside of conflict resolution. Power users may have keywords that work better for them and would want to set it outside of what the extension expects. | ||
| * [rob] Browsers should have a built-in way to handle this kind of customization. | ||
| * [oliver] Chrome tends not to provide extensions with ways to customize things that the browser UI itself does not. We would likely want to implement this first. | ||
| * [rob] … I'm not concerned about changing values at runtime as long as there's a way to narrow the list of possible values. | ||
| * [oliver] Would be interested in hearing from the developer whether a static list would address their concern. | ||
| * [rob] If browsers are on board with customizing the UI, I don't think there's a need to expose this API to extensions. That also minimizes the potential for abuse and glitches. | ||
| * [timothy] I don't know if other browsers currently do this, but it is possible that we would have a list of disallowed prefixes in browsers. | ||
| * [rob] We don't block values. If you don't like the keyword an extension registered, you can uninstall it. | ||
| * [timothy] If we supported this, either runtime or static, we'd likely have a way for the user to opt into customization. | ||
| * [simeon] Additional user consent changes how I'm thinking about this. | ||
| * [rob] I'm open to addressing this high level feature request, but also want to align with other vendors. Therefore I'd like to await Chrome's feedback first. | ||
|
|
||
| [PR 532](https://github.com/w3c/webextensions/pull/546): update window.browser spec | ||
|
|
||
| * [timothy] Stuck for a while on Patrick or Rob. | ||
| * [patrick] Devlin and Rob wanted to talk. There was some philosophical concern that needed to be resolved. | ||
| * [rob] Basically whether chrome and browser should be strict aliases or be distinct objects which may have different properties. | ||
| * [patrick] Right. I'll follow up with Rob and Devlin to further discussions. | ||
|
|
||
| [PR 560](https://github.com/w3c/webextensions/pull/560): Proposal: Multiple user script worlds | ||
|
|
||
| * [timothy] Non blocking from | ||
| * [rob] I just need to take a last look. I anticipate no major concerns. | ||
|
|
||
| [Issue 162](https://github.com/w3c/webextensions/issues/162): Declarative Net Request proposal: disable individual static rules | ||
|
|
||
| * [andrey] Continuing from my last comment at https://github.com/w3c/webextensions/issues/162#issuecomment-2016592462. At the in-person event we discussed increasing the limit on the number of rules that can be disabled. Devlin mentioned fast-track review as a possible mitigating factor reducing the need for change here. Review for submissions can currently take up to two weeks. Current 5000 limit does not cover 2 weeks. I'm hoping Chrome can consider a smaller increase, like 10000. | ||
| * [oliver] On my list to follow up on. | ||
| * [rob] Would you be okay if the first few requests processed by the browser do not account for these rules? One of the concerns motivating the current small size is the ability to guarantee that rules are processed on browser start. If we increase the size, we may have to asynchronously load the modified rule list. | ||
| * [andrey] Sounds like a minor nuisance. Probably not a big deal. For API design, we could potentially synchronously store the first 5000, have other rules load async. | ||
| * [rob] Would you be okay with having all overrides be async, i.e not guaranteed? | ||
| * [andrey] Would be more consistent if guaranteed, but this would be an acceptable exchange. We can live without guarantee if we don't have a too low limit. | ||
| * [andrey] Reason for asking for a slight increase is to minimize the amount of blockers on shipping quickly. | ||
|
|
||
| The next meeting will be on [Thursday, April 11th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=66172800,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