-
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 #742 from w3c/meeting-2024-12-19
Publish minutes of 2024-12-19 meeting
- Loading branch information
Showing
2 changed files
with
189 additions
and
7 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, Dec 19 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu[19 December 2024 | WebExtensions CG | W3C](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20241219T080000/) | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=6750ed00,384 | ||
| Call-in details: [WebExtensions CG, 19th December 2024](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20241219T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #735](https://github.com/w3c/webextensions/issues/735), [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 736](https://github.com/w3c/webextensions/issues/736): Selecting OK on confirm() is not considered a user gesture for permissions | ||
| * [Issue 737](https://github.com/w3c/webextensions/issues/737): A network request made from a worker is still subject to blocking rule(s) even when allowAllRequests is in place | ||
| * [Issue 740](https://github.com/w3c/webextensions/issues/740): Support userScripts permission in the permissions API | ||
| * **Timely issues** (10 minutes) | ||
| * [PR 739](https://github.com/w3c/webextensions/pull/739): Clarify behavior of userScripts API | ||
| * [PR 729](https://github.com/w3c/webextensions/pull/729): Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() | ||
| * [Issue 19](https://github.com/w3c/webextensions/issues/19): APIs and infrastructure to simplify cross-browser testing of extensions | ||
| * [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
| * [Issue 711](https://github.com/w3c/webextensions/issues/711): Proposal: Enable changing the permissions for only new user | ||
| * [Issue 733](https://github.com/w3c/webextensions/issues/733): Proposal: Add `isSyncable property` to BookmarkTreeNode | ||
| * [Issue 732](https://github.com/w3c/webextensions/issues/732): Proposal: Add `permanentNodeType` property to BookmarkTreeNode | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Sohail Rajdev (Microsoft) | ||
| 3. Oliver Dunk (Google) | ||
| 4. Simeon Vincent (Mozilla) | ||
| 5. Tomiislav Jovanovic (Mozilla) | ||
| 6. Timothy Hatcher (Apple) | ||
| 7. Kiara Rose (Apple) | ||
| 8. Mukul Purohit (Microsoft) | ||
| 9. David Johnson (Apple) | ||
| 10. Patrick Kettner (Google) | ||
| 11. Aaron Selya (Google) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 736](https://github.com/w3c/webextensions/issues/736): Selecting OK on confirm() is not considered a user gesture for permissions | ||
|
|
||
| * [rob] It is very easy to pop up a dialog, and to trick the user into pressing OK. | ||
| * [timothy] It is also relatively easy for extensions to capture a click in the web page. | ||
| * [timothy] This is not something for extensions, should we close it? | ||
| * [simeon] Sounds good by me. | ||
| * [tom] it's in the main html spec https://html.spec.whatwg.org/multipage/interaction.html#user-activation-processing-model | ||
|
|
||
| [Issue 737](https://github.com/w3c/webextensions/issues/737): A network request made from a worker is still subject to blocking rule(s) even when allowAllRequests is in place | ||
|
|
||
| * [timothy] This seems like a bug. Not clear what browsers this applies to. | ||
| * [oliver] allowAllRequests applies to frames, correct? | ||
| * [rob] A document and all of its subframes. | ||
| * [oliver] Undefined whether it applies to requests from a service worker, then. | ||
| * [timothy] SWs usually apply to a given document. | ||
| * [oliver] If we say it does apply to a SW, an allow request on one tab may apply to other tabs. Could do it based on what tab the SW is handling the request for? | ||
| * [rob] SW could receive a “fetch” event for a given tab. But if it in turn triggers another fetch, the tab context is lost for that request. | ||
| * [oliver] Seems tricky. Leaning towards maybe working as intended, but not sure. | ||
| * [rob] If they can propose a coherent strategy, I'd be in favor of changing it. E.g. for a dedicated Worker, that is owned by one document only, it may be feasible to define meaningful “allowAllRequests” behavior. But since a ServiceWorker (and SharedWorker) can be shared by multiple documents, it's not clear what should happen. Would be nice to solve the use case, but not sure how. | ||
| * [oliver] I will leave a comment. | ||
| * [simeon] Closing though, it's been weird to me as web developer that extensions cannot interact with requests handled by service workers. Would be nice to give extensions more visibility into pages, but not sure how. | ||
| * [timothy] Agree it would be nice to solve, prevent pages from hiding requests via service worker routing. | ||
|
|
||
| [Issue 740](https://github.com/w3c/webextensions/issues/740): Support userScripts permission in the permissions API | ||
|
|
||
| * [rob] (summarized issue) | ||
| * [oliver] Personally supportive. Chrome is open to this, but needs more discussion. | ||
| * [oliver] Would add that exposing whether or not the X api is available through permissions API is reasonable, don't want to provide a way to request this capability via the API. | ||
| * [rob] In Firefox, we do want to allow a request via API. We're addressing grant concerns with UI changes. Chrome can just immediately reject requests for this permission. | ||
| * [timothy] That's my preferred approach. Permissions are flexible. | ||
| * [rob] Does this discussion also translate to other APIs in the future where we also want optional only? May be a separate discussion. | ||
| * [timothy] I think it would establish precedent for other APIs, which is not a bad thing. | ||
| * [oliver] We've been discussing this in parallel. We're not going to do optional only, so might be strange to specify if only one browser does it. | ||
| * [rob] Since the only other browser to implement userScripts is Chrome, wondering if there's an action item for Chrome. | ||
| * [oliver] Don't know if you want to keep the issue open until we're supportive. Since this is a Chrome thing, I can look into it without an issue. | ||
| * [rob] Would be useful to signal status. | ||
| * [timothy] I'm supportive of the concept even though we don't have this API. Will add a supportive label. | ||
| * [rob] oliver, looking back on notes do you want to wait until you're supportive or implemented? | ||
| * [oliver] Need to discuss first internally. | ||
| * [rob] I'll add chrome:followup then. | ||
|
|
||
| [PR 739](https://github.com/w3c/webextensions/pull/739): Clarify behavior of userScripts API | ||
|
|
||
| * [timothy] Some things Rob noted when implementing userscripts. | ||
| * [rob] I included links to Chromium bugs (filed where there was no issue yet). Emilia provided some feedback and some suggestions have been implemented in Chrome. Not clear if she forgot to approve the PR. | ||
| * [oliver] I can follow up on that. | ||
|
|
||
| [PR 729](https://github.com/w3c/webextensions/pull/729): Add proposal for runtime.onEnabled and runtime.onExtensionLoaded events | ||
|
|
||
| * [timothy] Oliver and I approved this after some back and forth last week. | ||
| * [sohail] Thanks for that. Rob, have you had a chance to look at it? | ||
| * [rob] No, on my todo list. Noticed that this PR has addListener and removeListener, but not hasListener. Was this intentional? | ||
| * [sohail] No. | ||
| * [rob] So basically a regular extension event? | ||
| * [sohail] Correct. | ||
| * [rob] How would this work with async initialization? My concern is whether this will fulfill the majority of use cases. | ||
| * [sohail] Goal of this PR was to add similar functionality to onInstalled. | ||
| * [rob] Is this capability something developers are requesting? | ||
| * [sohail] Yes, a few developers have requested it in the issue. | ||
| * [mukul] Started as a developer request. | ||
| * [simeon] Rob, can you share more about the async init issue? | ||
| * [rob] Typically an extension wants to initialize once. The existing events were insufficient, leading to the request for the event which is being specified here. This works, except when initialization is interrupted. E.g. if the extension or background script terminates before the initialization completes. A work-around for that is to use the `storage.session` API to store a flag of initialization state at the end of the initialization. This helps with initializing once per browser session, but not across browser sessions. You can see this pattern in action in the PR I sent you for userscript API documentation. | ||
| * https://github.com/mdn/webextensions-examples/pull/576 | ||
|
|
||
| [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() | ||
|
|
||
| * [timothy] Devlin recently updated the PR, we should take another look. It's on my to-do list, I encourage others to do something similar. | ||
|
|
||
| [Issue 19](https://github.com/w3c/webextensions/issues/19): APIs and infrastructure to simplify cross-browser testing of extensions | ||
|
|
||
| * [kiara] Wanted to share a quick update. We've been meeting every other Tuesday among the browsers to discuss this. Safari has been working on a WebDriver classic spec to handle loading and unloading extensions. Next steps for us are to hook up WPT runner to support those commands and get a test up and running. Once we have that working, plan to share that here to give visibility into the structure of the tests that we have in mind. Have other browsers had an opportunity to land BiDi support for loading/unloading extensions? | ||
| * [patrick] Not yet. | ||
| * [tomislav] Not yet. Do these have a common test? | ||
| * [kiara] Yes, should work across all browsers. | ||
| * [tomislav] We have some code committed, but not sure it's compliant. | ||
| * [rob] Tom, did you mean WPT or our webdriver bidi support? | ||
| * [tomislav] WebDriver BiDi | ||
| * [kiara] Classic guidelines are that when you implement a spec, you also land a test for it. Not sure if that guidance also applies to BiDi. | ||
| * [timothy] Another minor update, added browser.test.sendMessage support to WebKit last week. Should be in line with the Chrome and Firefox implementations, so that's also available now. | ||
| * [rob] Callback or promise? Oh wait, test.sendMessage is just a fire-and-forget. | ||
| * [timothy] Doesn't have replies. Made it easy to implement ;) | ||
| * [kiara] For install/uninstall support, is there a timeline for other browsers to implement? | ||
| * [patrick] Nothing specific on the Google side. Should be relatively quick when a decision is made, but folks are out for the holidays. | ||
| * [tomislav] I'll be working on this. Should land in Nightly soo | ||
| * [rob] Bugs tracking implementation of the WebDriver BiDi commands in Firefox: | ||
| * https://bugzilla.mozilla.org/show_bug.cgi?id=1934551 | ||
| * https://bugzilla.mozilla.org/show_bug.cgi?id=1934553 | ||
| * As specified by https://github.com/w3c/webdriver-bidi/pull/778 | ||
| * [tomislav] Apple, is this Safari or WebDriver? | ||
| * [david] Being implemented in SafariDriver, so will require Safari. | ||
|
|
||
| [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
|
|
||
| * [rob] Carry-over from last meeting. I think Giorgio put it on the agenda to ask for a status update. Anyone in favor or opposed to injecting content scripts in workers? | ||
| * [timothy] Makes sense, but hasn't had many requests for it so low priority. | ||
| * [oliver] I can follow up on this. If we do have a proposal, we should specify in more detail what “matching” means in this context. Not clear what matching a browsing context means. | ||
| * [patrick] Suggest commenting on the issue so we don't lose track of that feedback. | ||
| * [rob] I think I understand what they're asking for. If there's a content script injected in the page, then we inject into workers as well(?) | ||
| * [timothy] Every worker has an origin. I think your original idea that matching based on the origin makes the most sense. | ||
| * [rob] Would like to see use cases to evaluate which API makes the most sense. | ||
| * [rob] I don't think that it would be realistic to implement logic like “if this document is matched, somehow run a content script in every worker reachable from this document”. If extensions really want that, they could declare a script for a worker origin, since workers can only be shared by documents from the same origin. | ||
| * [timothy] Agreed. | ||
| * [oliver] I'll leave a comment and follow up internally. | ||
|
|
||
| [Issue 711](https://github.com/w3c/webextensions/issues/711): Proposal: Enable changing the permissions for only new user | ||
|
|
||
| * [rob] We've discussed this before. The concrete next steps were for Chrome to consider how they want to approach it. | ||
| * [oliver] We have discussed this. A bit conflicted. As extension developers we can sympathize, but we don't want to make it too easy for extensions to request many (unnecessary) permissions. | ||
| * [rob] To be clear, with the current situation developers are incentivised to ask for as many permissions up front as possible to avoid the bad UX. | ||
| * [oliver] We are aware of that. | ||
|
|
||
| [Issue 733](https://github.com/w3c/webextensions/issues/733): Proposal: Add `isSyncable` property to BookmarkTreeNode | ||
|
|
||
| * [oliver] This issue was about indicating if a folder is synced. The name we're considering is `inAccount`. Feedback welcome. For context, we're trying to avoid using “sync” in user facing strings. Sync is well used in existing APIs, so there's a consistency argument there. | ||
| * [timothy] Prefer sync over inAccount, being generic eases adoption by other browsers. | ||
| * [rob] I'm not immediately sold on the account naming. In other APIs we use account and it's not clear what that means. Does the meaning of “sync” match what's used in storage.sync? | ||
| * [oliver] I think it largely matches. | ||
| * [rob] In that case I'm in favor of `isSyncable`. Other names are still welcome. | ||
| * [oliver] In `storage.sync`, extensions can add entries even without being logged in. In this case, it only appears when logged in. | ||
|
|
||
| [Issue 732](https://github.com/w3c/webextensions/issues/732): Proposal: Add `permanentNodeType` property to BookmarkTreeNode | ||
|
|
||
| * [oliver] The name we had in mind there was `systemNodeType`. | ||
| * [rob] Any opinions on the Safari side? | ||
| * [timothy] Don't know if system needs to be in the name if there's already a nodeType(?) | ||
| * [oliver] There's already a BookmarkTreeNode.type. | ||
| * [timothy] Maybe `nodePurpose`? Or maybe just `purpose` makes sense? | ||
| * [tomislav] Something like ownership may make more sense? | ||
| * [rob] What stops us from reusing nodeType and expanding the supported values? | ||
| * [oliver] It is still a folder. If you're building UI that wants to show different types of folders, you may want to change the icon based on the type, for example. | ||
| * [rob] Call it `folderType`, since only folders can have this? | ||
| * [oliver] Can't think of a reason not to. | ||
| * [timothy] I like that, feels nice. | ||
|
|
||
| The next meeting will be on [Thursday, January 16th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=67884c00,384). We have cancelled the January 2nd meeting. |
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