-
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 #537 from w3c/meeting-2024-02-01
Publish minutes of 2024-02-01 meeting
- Loading branch information
Showing
2 changed files
with
152 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,149 @@ | ||
| # WECG Meetings 2024, Public Notes, Feb 1 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=65badf00,3c0 | ||
| Call-in details: [WebExtensions CG, 1st February 2024](https://www.w3.org/events/meetings/9b102b5e-bc73-42a2-8b39-73f84833beac/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #530](https://github.com/w3c/webextensions/issues/530), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **New Issues** | ||
| * [Issue 531](https://github.com/w3c/webextensions/issues/531): Proposal: New agenda template for public meetings | ||
| * [PR 529](https://github.com/w3c/webextensions/pull/529): Add permissions.requestSiteAccess() API proposal | ||
| * [Issue 524](https://github.com/w3c/webextensions/issues/524): Pre-rendering in new tabs and window ID behaviour | ||
| * [Issue 532](https://github.com/w3c/webextensions/issues/532): Determine the nuances of aliasing chrome and browser | ||
| * **Carry-over from previous meetings** | ||
| * From previous discussion queue: | ||
| * 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 | ||
| * **Topics nominated for the agenda but not discussed due to time constraints** | ||
| * [Issue 454](https://github.com/w3c/webextensions/issues/454): Add a new manifest key to include a origin trial token (anton?) | ||
| * [Issue 519](https://github.com/w3c/webextensions/issues/519): Proposal: Event.addListener should accept an interface. | ||
| * [Issue 517](https://github.com/w3c/webextensions/issues/517): sidePanel API: lifecycle events | ||
| * [Issue 520](https://github.com/w3c/webextensions/issues/520): Increase maximum total size (QUOTA_BYTES) for storage.sync | ||
| * [Issue 521](https://github.com/w3c/webextensions/issues/521): sidePanel API: sidePanel.close() and sidePanel.toggle() | ||
| * [Issue 522](https://github.com/w3c/webextensions/issues/522): Proposal: Give extensions easy access to MediaSession | ||
| * [Issue 523](https://github.com/w3c/webextensions/issues/523): API limitation: content scripts URL matches and History API, Navigation API, BFCache | ||
| * [Issue 527](https://github.com/w3c/webextensions/issues/527): chrome.scripting.executeScript doesn't resolve/reject for frozen state tabs | ||
| * [Issue 528](https://github.com/w3c/webextensions/issues/528): Inconsistency: chrome.downloads.open() return value | ||
| * [Issue 533](https://github.com/w3c/webextensions/issues/533): Enhance browser.storage.local to allow storing binary data directly | ||
| * [Issue 534](https://github.com/w3c/webextensions/issues/534): Inconsistency with indexedDB in browser extensions | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Patrick Kettner (Google) | ||
| 3. Giorgio Maone (NoScript, Tor) | ||
| 4. Oliver Dunk (Google) | ||
| 5. Todd Schiller (PixieBrix) | ||
| 6. Kiara Rose (Apple) | ||
| 7. Timothy Hatcher (Apple) | ||
| 8. Sam Macbeth (DuckDuckGo) | ||
| 9. Tim Heflin (Keeper) | ||
| 10. David Johnson (Apple) | ||
| 11. Richard Worth (Capital One) | ||
| 12. Mukul Purohit (Microsoft) | ||
| 13. Anton Bershanskyi | ||
| 14. Devlin Cronin (Google) | ||
| 15. Emilia Paz (Google) | ||
| 16. Simeon Vincent (unaffiliated) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 531](https://github.com/w3c/webextensions/issues/531): Proposal: New agenda template for public meetings | ||
|
|
||
| * [timothy] Proposal from Oliver that has been discussed with us. Suggestion to ensure that we can discuss more than just brand-new issues in the meeting. | ||
| * [timothy] We're going to use this new template in the next meeting two weeks. | ||
| * [oliver] As is evident from the agenda this week, the list of topics is not prioritized. The proposal enables us to discuss the topics that are most important. | ||
|
|
||
| [PR 529](https://github.com/w3c/webextensions/pull/529): Add permissions.requestSiteAccess() API proposal | ||
|
|
||
| * [emilia] I'm Emilia Paz from Chrome extensions team. This proposal is a way to allow extensions to signal that they'd like to run. There is currently no way to do so unless there is an explicit user action (going through settings, permissions.request() requires user interaction). The method does not take a URL, but documentId/tabId. | ||
| * [timothy] In Safari we require host permissions to request anything that is sensitive to privacy. We don't expose tab URL unless host permissions have been granted. This applies to all APIs, not just tab. That makes it hard for extensions to execute scripts in a tab. I think that there is value in a declarative way to do it, e.g. register match patterns and reasons / friendly user description that can bubble up. | ||
| * [devlin] We're exploring ways to enable extensions to tell where it wants to run and not. In Chrome, we are planning to always have an indication where an extension says where it wants to run. That is independent of the proposal. In the UI there is however a lack about the level of expressed noise. An extension that wants to run on every site should not trigger an interstitial on every site. The API allows extensions to signal that they really want to run on the site, even if an extension may support more sites. An alternative for them is to open a new tab which would be disruptive. For example, for a shopping extension, we don't want the extension to run on amazon.com, but on specific sections on Amazon where a coupon is available. We want the API ergonomics of the API to encourage minimal use, on specific sites where this is really needed (and potentially suppress requests or reduce obviousness of the notification if needed). | ||
| * [devlin] Safari's design is interesting. Would you be open to make the tab URL visible if the extension declares access to the URL? | ||
| * [timothy] We consider the URL sensitive, not just concerned about script execution on the page. | ||
| * [devlin] For this reason, the “tabs” permission has a permission warning. | ||
| * [rob] What's relevant to this discussion - Safari doesn't show warnings for permissions, correct? | ||
| * [timothy] That's correct. We don't show warnings other than host permissions. It's a slightly more restricted model than other browsers. | ||
| * [timothy] Expectation is that extensions are going to do this anyway - where the extension is going to compare URLs with a database and trigger the API. The declarative way would be more privacy-preserving. | ||
| * [devlin] In a perfect world, that would be true. | ||
| * [timothy] We could potentially offer that by disallowing wildcard paths. | ||
| * [devlin] In the example of Grammarly on Google Docs, the extension would probably want to run on every docs.google.com. | ||
| * [tomislav] While I agree with the goals, I don't see why it would be useful to specify a tabId instead of the exact URL. User could have multiple tabs on the same URL. Possible way forward is a dynamically updatable set of URLs. | ||
| * [oliver] Discussion on the issue requesting background access to this. Linking the request to the tabId. (... - see comments on the pull request for the discussion) | ||
| * [tomislav] What do you expect other than the URL for the extension to base the decision on? Example you gave is “is webshop URL in database, then show the notification” can be covered by a declarative API. | ||
| * [rob] In that example, the extension owner may not want to share the entire database with an extension. | ||
| * [rob] The main issue with tabId is regarding time of check, time of use. The tab could have been navigated between API call and display of notification, similar to the tabs/scripting.executeScript API as raised in [issue 8](https://github.com/w3c/webextensions/issues/8). | ||
| * [devlin] We discussed this internally while designing the API. In this API we support documentId for that issue. Unlike the scripting API, the implications of showing the notification is relatively minor. | ||
| * [devlin] Returning to the question of Tomislav about whether we can declaratively do so. Other than the extension not wanting to share the full set of patterns, we also don't want extensions to offload a large number of such declarative patterns to the browser. We don't want this to be a persistent state, and are clearing the notification on cross-origin navigation. | ||
| * [devlin] About the question of signals other than the URL, e.g. tab focus, settings, extension-specific options. | ||
| * [devlin] This proposal is not the only way extensions can signal where to run. It is to offer extensions a way in case the default way of signaling where to run is not sufficiently noisy. We noticed during testing that users easily miss the lack of extension not running when needed. | ||
| * [timothy] We solve that with badging, especially on iOS Safari. | ||
| * [devlin] We want to introduce a noisier notification, and that requires a way to signal only when needed. | ||
| * [timothy] To second Rob, I still see a race condition with tabIds. For example, a shopping extension checks the user's current page, but doesn't get a response until after the user has navigated to another page. | ||
| * [devlin] Not security/privacy issue, the worst that can happen is that the extension triggers a notification and it appears on the wrong site. | ||
| * [timothy] Could be part of an attack chain, where a malicious site uses a quick redirect to trigger the prompt, then gets access on another page. | ||
| * [devlin] That's always a concern with extensions. Not particularly novel here. | ||
| * [rob] This discussion has taken 30 minutes of the meeting, I suggest continuing async. | ||
| * [devlin] On Chrome we are looking towards experimenting with this, and want to have a way for extensions to signal that and want to start soon. | ||
|
|
||
| [Issue 524](https://github.com/w3c/webextensions/issues/524): Pre-rendering in new tabs and window ID behaviour | ||
|
|
||
| * [oliver] When a new tab is opened and prerendered, the tabId/windowId is not known yet. Last meeting we discussed this, the suggestion was to use the windowId of the initiator. | ||
| * [devlin] The issue with this is that while it makes sense for events, it is a problem for interaction between APIs. E.g. what should the tabId be? A magic windowId would solve the issue. | ||
| * [rob] What is the issue against an arbitrary window ID? Whether a tab is prerendered or not ought not make a difference in the windows API. | ||
| * [devlin] For clarity, you're saying there's window 1, 2, 3, and prerendering occurs, so that's placed in window 4. Issues are related to window height/width. How would we handle allowing/denying that kinds of concept that's tied to UI when there is no UI for prerendered content? A null window ID would better reflect the realities of how this is handled. | ||
| * [rob] Propose we table this and continue discussions async. | ||
| * [rob] Magic windowId is a new negative one, not WINDOW_ID_NONE (-1), right? | ||
| * [devlin] I would be fine with either. Mild preference for -1. | ||
| * [timothy] I would be fine with that. | ||
| * [tomislav] Same. | ||
|
|
||
| [Issue 532](https://github.com/w3c/webextensions/issues/532): Determine the nuances of aliasing chrome and browser | ||
|
|
||
| * [timothy] About the browser namespace in Chrome. | ||
| * [patrick] At TPAC we agreed to move the chrome namespace over to the browser namespace. As part of Chrome's implementation a spec is required, which we have published. Now we want to figure out what to do here. | ||
| * [timothy] In Safari, chrome and browser are identical. | ||
| * [rob] In MV3 the chrome and browser namespaces are identical, but in MV2 they were distinct because developer expectations were different between browsers. This also applies to content scripts. | ||
| * [tomislav] I think it may be a separate object, but with the same API surface exposed. | ||
| * [patrick] That matches what I'm seeing. That's what I'm referring to as a clone. | ||
| * [patrick] What Chrome is considering is that browser and chrome are separate objects, but with the individual namespaces being identical objects. Main reason is there are some properties on the Chrome namespace that are not browser-specific (csi, loadTimes). | ||
| * [devlin] Right, there are some properties that, if they are direct aliases, we would have to carry over (chrome.csi, chrome.loadTimes, etc.). | ||
| * [rob] Have you considered prototypical inheritance? Just wondering because it is a common web platform approach to it, not saying that you should because there are issues, e.g. `Object.keys(chrome)` would not return all namespaces. | ||
| * [devlin] Not considered, can see concern with extension compatibility. | ||
| * [tomislav] I think we'd be open to aligning on behavior, either Chrome's or Safari's, in order to reduce custom behaviors. | ||
| * [timothy] Preference for Safari's approach where the values are identical, but if we align I am willing to adjust. | ||
| * [patrick] Should we add `chrome` to the spec we just published? | ||
| * [rob] `chrome` at this point is for backcompat. If in the future chrome is an artifact of the past, and a new WebExtensions implementation emerges, then it should not be forced to support both `chrome` and `browser`. | ||
| * [timothy] I think we should say somewhere that they're aliases. For example, if a developer adds an event listener deeply. | ||
| * [devlin] I think we should specify this in WECG, not in the browser spec. | ||
|
|
||
| Rediscussion of [Issue 103](https://github.com/w3c/webextensions/issues/103): arguments and workers in registerContentScripts() | ||
|
|
||
| * [timothy] Ability to use func and args in registerContentScripts(), and to allow worlds to be declared in other content script registrations. | ||
| * [oliver] With the userScripts API defined, are there remaining issues to address? | ||
| * [giorgio] Reason behind this proposal is to have a reliable way to parametrize content scripts for the main world. This means that the content script runs everywhere and configurations everywhere. Should also apply to workers. Running in workers doesn't make sense for user scripts. | ||
| * [rob] I recognize the use case, which is why I suggested a way to define args/func as a generic solution in the userScripts API discussions before (https://github.com/w3c/webextensions/issues/279#issuecomment-1309614401). | ||
| * [devlin] Oliver, has the dynamic params for the content scripts API been discussed at all? | ||
| * [oliver] No | ||
| * [devlin] Quick context: … Original idea wasn't to use args and func. Instead, something like setDynamicParams. | ||
| * [giorgio] Which could be configured per URL, right? | ||
| * [devlin] Exactly. Expectation is the content script would be static, but the configuration would change depending on injection context. | ||
| * [rob] The scripting.globalParams approach has been raised before ([Issue 284](https://github.com/w3c/webextensions/issues/284): Main world User Script shared params). One issue with this design is that it works in the isolated world, but it doesn't work in the main world, which is the use case that Giorgio here is interested in. | ||
| * [devlin] Hmm…. Okay. Ideally we should not have two ways to do it. One solution that works for all cases is preferable. | ||
| * [giorgio] Any signal on worker support? | ||
| * [rob] Please open another issue for that, as it's distinct from what we're discussing in this issue. | ||
|
|
||
| The next meeting will be on [Thursday, February 15th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=65cd5400,3c0) |
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