-
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 #734 from w3c/meeting-2024-12-05
Publish minutes of 2024-12-05 meeting
- Loading branch information
Showing
2 changed files
with
181 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,178 @@ | ||
| # WECG Meetings 2024, Public Notes, Dec 5 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=6750ed00,384 | ||
| Call-in details: [WebExtensions CG, 5th December 2024](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20241205T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #727](https://github.com/w3c/webextensions/issues/727), [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 730](https://github.com/w3c/webextensions/issues/730): XHR from content scripts should not be affected by page's CSP / Permissions-Policy | ||
| * [Issue 731](https://github.com/w3c/webextensions/issues/731): Incorrect application of "domainType: thirdParty" in DNR - blocking direct access to iana.org when opening a new tab | ||
| * [Issue 729](https://github.com/w3c/webextensions/pull/729): Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events | ||
| * **Timely issues** (10 minutes) | ||
| * [Issue 732](https://github.com/w3c/webextensions/issues/732): Proposal: Add permanentNodeType property to BookmarkTreeNode | ||
| * [Issue 733](https://github.com/w3c/webextensions/issues/733): Proposal: Add isSyncable property to BookmarkTreeNode | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [Issue 539](https://github.com/w3c/webextensions/issues/539): RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection | ||
| * [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. David Johnson (Apple) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Tomislav Jovanovic (Mozilla) | ||
| 4. Dmitriy Seregin (AdGuard) | ||
| 5. Sohail Rajdev (Microsoft)) | ||
| 6. Shivam Chawla (Microsoft) | ||
| 7. Oliver Dunk (Google) | ||
| 8. James Lee (Google) | ||
| 9. Monica Basta (Google) | ||
| 10. Maxim Topciu (AdGuard) | ||
| 11. Kiara Rose (Apple) | ||
| 12. Timothy Hatcher (Apple) | ||
| 13. Simeon Vincent (Mozilla) | ||
| 14. Mukul Purohit (Microsoft) | ||
| 15. Aaron Selya (Google) | ||
| 16. Carlos Jeurissen (Jeurissen Apps) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 730](https://github.com/w3c/webextensions/issues/730): XHR from content scripts should not be affected by page's CSP / Permissions-Policy | ||
|
|
||
| * [giorgio] In MV2 this worked out of the box, in MV3 in Firefox this does not work out of the box, where XHR follows the same policy as main world content scripts. I would expect to be able to relax the CSP (connect-src) or use the isolated world's content script, like Chrome. | ||
| * [timothy] The fact that we have so many CSP issues might be a good sign of needing content-script-specific CSP in content scripts. | ||
| * [rob] Not exactly the same issue, in Firefox, we explicitly made the CSP that applies to content scripts the same to the page's for mv3. If we want to have a different behavior, we should specify exactly the desired behavior. | ||
| * [giorgio] I agree that the behavior should be specified. | ||
| * [rob] At a high level, what kind of exceptions do we want to make? We don't make (many) changes to web platform APIs in content scripts. Historically XHR/fetch had different behaviors in MV2. Google folks, are there things beyond CSP that are excepted? | ||
| * [giorgio] Not a difference between Chrome and Firefox, really. Synchronous XHR limitations are applied to content scripts. Can be worked around using DNR rules. Hack on a hack, but we don't have a meaningful API to address this. | ||
| * [oliver] From an ergonomics point of view this sounds useful. | ||
| * [rob] I know Chrome made an effort to have content scripts use the page's CSP, but not well documented. If this is only a CSP thing, then it may be easier to resolve than if there are many other undocumented exceptions. | ||
| * [oliver] I expect we're unlikely to break this unless there's a significant issue. | ||
| * [giorgio] If you could document intent to synchronize behavior, I'll stay on the current Firefox behavior (MV2) for now. | ||
| * [oliver] I'll follow up and leave a comment. | ||
| * [rob] Apple folks - what does Safari do here? | ||
| * [timothy] I'll have to test to see what our behavior is in this situation. | ||
|
|
||
| [Issue 731](https://github.com/w3c/webextensions/issues/731): Incorrect application of "domainType: thirdParty" in DNR - blocking direct access to iana.org when opening a new tab | ||
|
|
||
| * [dmitry] Title may be inaccurate. We thought the problem was with initiator domain. Five hours ago I found another case where our requests are not blocked. Main issue is with DNR rules blocking third party requests. We expect that opening a document in a new tab would be a first party request. Seems like a mistake in logic. | ||
| * [timothy] Agree that it sounds like a bug. Not sure what we do, but I know new page loads are treated as first party. | ||
| * [kiara] I just tested, Safari doesn't block with these rules. | ||
| * [rob] Was this observed in Firefox? | ||
| * [simeon] Yes, noted in the issue description. | ||
| * [oliver] I know we had some discussion about links from 3rd party applications. Might be worth linking. I know the web's concept of first party does not directly match DNR's definition or any other concept. | ||
| * [rob] I deferred implementation of `domainType` in Firefox because of the lack of a clear definition of "first-party". Ended up mirroring Chrome's implementation, which is modeled after adblocker rules, as described at https://bugzilla.mozilla.org/show_bug.cgi?id=1797408#c6. | ||
| * [rob] From the address bar there is no initiator, which is what leads to the classification as third party (request domain differs from absent domain). If there's consensus, I'm open to changing the implementation. We should make sure to check with extension developers before making changes. DNR rules do not apply to main_frame by default, so the negative impact of changing the behavior may be negligible. | ||
| * [timothy] In my opinion it's rare that a main frame document load would be blocked. Should be hard for that to be the case. Things like this where it's accidentally blocking main frame should be rare. | ||
| * [rob] Sounds like a devrel task to figure out if we can make this change. | ||
|
|
||
| [PR 729](https://github.com/w3c/webextensions/pull/729): Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events | ||
|
|
||
| * [sohail] PR for [issue 353](https://github.com/w3c/webextensions/issues/353): Support onEnabled event when the extension from disabled state to enabled state | ||
| * [sohail] Chromium implementation bug: https://crbug.com/1513560 | ||
| * [sohail] Formal proposal based on Google's proposal. | ||
| * [oliver] Any notable changes from previous discussion or is it the same | ||
| * [sohail] Same as previous chromium discussion. | ||
| * [rob] Who on Apple's side should be tagged as a reviewer? Oliver on Chrome, me on Firefox. I'll tentatively add Timothy for Apple. | ||
| * [simeon] Anything in particular we should discuss about this today or is it just an FYI? | ||
| * [sohail] Just an FYI. | ||
| * [tomislav] What's the stage internally for Chromium? | ||
| * [oliver] I believe Sohail from Microsoft are proposing to implement this. | ||
| * [mukul] I believe we heard from Chrome that they were open to it but didn't have the bandwidth to do it, so we're taking it on. | ||
|
|
||
| [Issue 732](https://github.com/w3c/webextensions/issues/732): Proposal: Add permanentNodeType property to BookmarkTreeNode | ||
|
|
||
| * [oliver] Looking further into the future, looking at changes to bookmark folders. Before making changes we'd like to look at use cases that are useful to extensions to make it easier to manage bookmarks. Current (Chrome) extension developers look at the ID. There are edge cases where the ID can change. Devs fall back to string matching. In Firefox the ID isn't numerical. This proposal introduces a new property to identify what are special nodes and what type they are. James and Monica are here from Chrome, they're working on the bookmark changes. | ||
| * [monica] Thanks Oliver, no additional notes at the moment. | ||
| * [rob] Is there any documentation about the upcoming changes? | ||
| * [oliver] The other issue (733) points to a blog post. | ||
| * [james] Probably a bit early to share beyond what's in the public post. | ||
| * [monica] To give a general idea, today all bookmarks are local or synced. We're introducing another model where some are local, some are account synced. There may be more than one bookmark bar folder, one for local account and one for synced content. | ||
| * [simeon] Is is possible for items to be interposed? | ||
| * [monica] In the extension API they will be separate. | ||
| * [rob] Would permanentNodeType be inherit by bookmarks, e.g. BOOKMARKS_BAR on individual bookmarks, or just the folder at the top level? | ||
| * [monica] The folders are typed, the nodes inside them are normal, so they need to be separate. | ||
| * [rob] As an extension developer I've had to parse the content of a bookmark to figure out it's type, so having an explicit field would be welcome. Oliver, you mentioned extensions parsing the ID - do you have an analysis of use cases to share? I'd like to make sure that what we design matches with actual uses. | ||
| * [oliver] Nothing off hand, but we can share examples of what we've seen in the wild. It seemed like Chrome, Edge, and Safari had similar concepts for what is synced. | ||
| * [timothy] We don't currently support the Bookmarks API so we'd need to look into it. I don't have details on all of the special cases that we have, but what's been discussed so far sounds good. We should be able to work with it. | ||
| * [tomislav] I think I heard two different things from Oliver and James/Monica. Are we trying to standardize types or are we expecting that they will be browser specific? | ||
| * [monica] This is what we have in Chrome. Oliver? | ||
| * [oliver] For something like the bookmarks bar, it would be nice to be consistent across browsers. Can have additional discussions about what we do for concepts that are more browser specific. | ||
| * [rob] I'd also like to take this discussion to the relevant product team. Can you provide descriptions/screenshots/links for what these types mean, to make the mapping to other browsers easier? | ||
| * [monica] We can do that. | ||
|
|
||
| [Issue 733](https://github.com/w3c/webextensions/issues/733): Proposal: Add isSyncable property to BookmarkTreeNode | ||
|
|
||
| * [oliver] This is addressing the other part of the problem. You may have a situation where you have two toolbar nodes where one is synced and one isn't. This would allow you to distinguish between them. | ||
| * [monica] Syncable won't just be added to bookmark bar, will be added to all nodes. Will allow developers to distinguish between what is syncable, what's local, etc. | ||
| * [tomislav] All nodes or all directory nodes? | ||
| * [monica] All nodes. | ||
| * [rob] Is this something that extension developers can set? And if not set, what is the default? | ||
| * [monica] Depends on the location of the bookmark. Not expecting to set it. | ||
| * [rob] If this applies to all nodes, then I would expect it to be configurable, so that extension developers can consciously choose whether it should be syncable. | ||
| * [monica] In the future with the changes we're making, you can distinguish between bookmarks tied to an account and syncable or not. If you don't want it synced, put it in a folder that isn't syncable. If you do, put it in a folder that is syncable. | ||
| * [tomislav] As I read it, everything under those top folders inherits the syncable state. | ||
| * [monica] Exactly. Also depends on the changes we're making. There's no mixed state today. As part of our changes, we will be able to support a mix of syncable state. | ||
| * [rob] From the API perspective, Are you proposing this as a property that can be read or queried? | ||
| * [monica] A read only property. | ||
| * [rob] If bookmarks.create() can take an isSyncable option, the API could throw an error if the specified value does not match the folder's configuration. | ||
| * [timothy] Multiple bookmark bars in the UI, or multiple bookmark bar folders? | ||
| * [monica] In the bookmark manager there will be two bookmark folders. | ||
| * [oliver] An extension may want to put [sync] or an icon next to items to distinguish them. | ||
| * [monica] To clarify, we're introducing this to allow developers to distinguish between local and sync items, but the broader data model for bookmarks remains the same. Don't want to have the assumption that it's always possible to choose whether an individual bookmark is or is not synced. | ||
| * [simeon] I may have misunderstood. Monica, I thought you said in the future a single folder could contain synced and non-synced items. Is that the intent? | ||
| * [monica] No, content can't be mixed. That's why we have the folder distinction. | ||
| * [timothy] I'm okay with the proposal, but think that it would be nice to not specify the requirement of the syncable state required to inherit from the top folder. | ||
| * [tomislav] Timothy, I think you're suggesting that we shouldn't specify the planned chrome behavior. | ||
| * [timothy] That's what I was originally thinking, but I'm not sure how that would work. Just wanted to be as flexible as possible. | ||
| * [david] I think that makes sense. You might have other bookmarks set by device management that aren't syncable. | ||
| * [oliver] Perhaps an enum? Not sure if that's feasible. | ||
| * [rob] Before we dive into the specifics, we should consider why developers care and whether the design makes sense for their use cases. | ||
| * [monica] If you have two bookmark bar folders, would it be useful to know what the sync behavior difference is between them? | ||
| * [rob] That sounds useful. On the fly use case: If an extension wants to create a bookmark in the toolbar and make sure they're not synced, how would a developer specify that? | ||
| * [monica] I don't think you'd be able to do so. In general today when you create a bookmark you need to create it in a given folder. When you decide where to put a bookmark, you can check whether or not the folder is syncable. Devs should not assume whether or not a folder is syncable. | ||
| * [james] To take a concrete example, if the user is not logged in there will be no syncable folders. That's the opposite of your example, but devs shouldn't assume all content is of a single type. | ||
| * [oliver] Agree with the use case of a fully private extension, but if we cannot guarantee it in the browser, we cannot implement it. | ||
| * [monica] Not possible to add restrictions to bookmarks to prevent an item from being moved to an account folder. | ||
| * [rob] Firefox is neutral on this. | ||
| * [timothy] Neutral as well for Safari. | ||
|
|
||
| [Issue 539](https://github.com/w3c/webextensions/issues/539): RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection | ||
|
|
||
| * [giorgio] When we last discussed this issue Oliver noted that there was a proposal to inject properties. I wanted to check if there was any progress on supporting globals for the register content script API. What I've gathered porting NoScript to MV3 is that we've got a lot of bug reports related to … that can be covered by DNR session rules + sync XHR. If scripting.registerContentScripts can support similar filters (URL or tabId filter), I wouldn't have to use such fragile work-arounds. | ||
| * [rob] Question: you mentioned no support for register by URL. Content script matching by URL is supported, isn't it? | ||
| * [giorgio] Parameters. Can declare fixed scripts but cannot set parameters for content scripts by tabID or URL. | ||
| * [rob] If you had a choice, would you prefer a way to declare parameters per URL or have sync IPC? | ||
| * [giorgio] Sync IPC would be great, but I don't expect you'd want that. Just need sync messaging once at tab start. | ||
| * [rob] Sync IPC would be unlikely. A more reasonable proposal may be synchronously available storage available in a content script. What kind of quota would you need? | ||
| * [giorgio] If you can't filter by URL and tab, I'm not sure. It depends on the user. | ||
| * [oliver] Global params or per-tab params are definitely still the path we'd like to take. I realize there's been a multi-year delay. Realize adding per-tab is similar in scope to global params, so neither path is obviously easier than the other. | ||
| * [giorgio] 10 MB if there's no filter. | ||
| * [rob] That's … a lot. From the API design point of view, it would be preferable for extensions to be able to specify different values, so that they are not forced to use one giant global `scriptParams`. | ||
| * [oliver] Does it need to be filtered by the key or the tab? | ||
| * [giorgio] Tab. Need to know in a given tab that you do or don't have to do a particular set of stuff. | ||
| * [timothy] How do you even know the tab id for the first load? By the time you know the tab ID you're already in the middle of the page load. | ||
| * [giorgio] User uses the UI to configure settings for a tab, then reloads the page. | ||
| * [simeon] Does that mean the settings aren't persisted for the URL in that tab? | ||
| * [giorgio] Correct. | ||
| * [timothy] That may work for your implementation, but it doesn't sound sufficient for the general case. | ||
| * [rob] The general use case is to have a default registration independent of tabId, which works across restarts. During a browser session, a user can have the desire for temporary exceptions, for which they can register tab-specific rules/scripts/whatever. | ||
| * [giorgio] DuckDuckGo does something similar. Not just declarative net request. | ||
|
|
||
| [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
|
|
||
| * (Skipped due to time limitations) | ||
|
|
||
| The next meeting will be on [Thursday, December 19th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=67636200,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