diff --git a/_minutes/2024-09-12-wecg.md b/_minutes/2024-09-12-wecg.md new file mode 100644 index 00000000..cafe7cf1 --- /dev/null +++ b/_minutes/2024-09-12-wecg.md @@ -0,0 +1,158 @@ +# WECG Meetings 2024, Public Notes, Sep 12 + + * Chair: Timothy Hatcher + * Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=66e22f00,384 +Call-in details: [WebExtensions CG, 12th September 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240912T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #682](https://github.com/w3c/webextensions/issues/682), [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 683](https://github.com/w3c/webextensions/issues/683): Feature request. More granular Extension's hotkeys scope + * [Issue 684](https://github.com/w3c/webextensions/issues/684): Feature request: enabled user gestures for omnibox events + * **Timely issues** (10 minutes) + * [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() + * [PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() + * [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API + * [PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API + * [PR 675](https://github.com/w3c/webextensions/pull/675) : Proposal : Add developer tools contexts in runtime.getContexts() + * **Check-in on existing issues** (20 minutes) + * [Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024 + + +## Attendees (sign yourself in) + + 1. Oliver Dunk (Google) + 2. Rob Wu (Mozilla) + 3. Timothy Hatcher (Apple) + 4. Aaron Selya (Google) + 5. Giorgio Maone (Tor, NoScript) + 6. David Johnson (Apple) + 7. Rémi Pujo (Dashlane) + 8. Sohail Rajdev (Microsoft) + 9. Solomon Kinard (Google) + 10. Mukul Purohit (Microsoft) + 11. Simeon Vincent (Mozilla) + 12. Kiara Rose (Apple) + 13. Jordan Spivack (Capital One) + 14. Tim Heflin (Keeper) + 15. Carlos Jeurissen (Jeurissen Apps) + + +## Meeting notes + +[Issue 683](https://github.com/w3c/webextensions/issues/683): Feature request. More granular Extension's hotkeys scope + + * [oliver] As I understand it, it is like commands that we have today, except limited to when specific URLs are being displayed. + * [timothy] Not necessarily focused on the page, but also including when the tab is being hovered on or active? + * [oliver] I think that it would be useful to clarify. + * [rob] I'd be interested in hearing the exact use case too. From my own experience as an extension developer (of a PDF Viewer), where the extension wants to customize the printing experience, Ctrl+P is intercepted. This does not work when the browser UI is focused even if the extension is displayed in the tab. This is a use case where a browser-global shortcut handler could add value over extension scripts and content scripts. + * [oliver] Also interested in complexity, and shortcut conflicts. + * [timothy] Commands are global, having controls when they are active would be useful. + * [oliver] I think that I'd be in favor of limiting shortcuts to one extension. + * [rob] Extensions can already do this by limiting shortcut handling to when specific conditions are met. + * [timothy] There could still be confusion when multiple extensions register it. + * [rob] I'm not opposed to the capability request, but would like some more detailed description of desired behavior and then discuss the specifics. + * [simeon] Would like to see more use cases. Open to paving cow paths, but I'm especially interested in things that can't currently be done. + +[Issue 684](https://github.com/w3c/webextensions/issues/684): Feature request: enabled user gestures for omnibox events + + * [rob] Sounds reasonable. + * [oliver] Devlin added a comment that we are supportive from the Chrome side. + * [oliver] Jackie asked about activeTab. + * [rob] Why not active tab? User is clearly invoking extension functionality. + * [oliver] Maybe onInputEntered is okay, but I was thinking of other events. + * [rob] So you would be okay with granting activeTab when the user presses enter, but not when the user is just typing. + * [simeon] Granting onInputEntered could be racy as you get a grant for a short moment before triggering a navigation. + * [david] No different from interaction with an extension button. + * [oliver] I think it is common to navigate to a new page when you press Enter from the omnibox. + * [rob] Going back, I'm okay with granting user gestures in onInputEntered. Also okay with granting activeTab. + * [timothy] I agree. + * [oliver] There is an open CL as well. + * [rob] Does that CL also cover activeTab? + * [oliver] I don't think so. + * [rob] Could you get it clarified? + * [oliver] Yes. We would likely decouple it from the current CL though. + * [rob] If not supported it could be a simple documentation fix, otherwise we could all consider implementing activeTab. + * [timothy] In our implementation, granting a user gesture also implies activeTab. Would be difficult to decouple. We don't support omnibox yet, but the behavior would be similar. + +[PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() + + * [timothy] I haven't reviewed the proposal yet. + * [rob] I left a review. This is a follow-up to our San Diego meeting, and nothing too surprising. We can continue async here. + +[PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() + + * [timothy] This PR is about communicating between multiple worlds, goes hand in hand with the dom.execute proposal(). + * [oliver] I saw a comment about worldId. + * [rob] locking to worldId. Relatively minor, can resolve. API is called messagePort. May be somewhat confusing to use the same name as another API. Current proposal does not address prototypes – this is important for making sure the web page can't intercept message passing. In practice this means using a null prototype. This is covered in my feedback so far. + * [oliver] Is there a potential risk of one extension leaking the prototype? + * [rob] Yes, since it's in the main world it would be shared with all extensions. Any extension leaking could compromise others. A solution could be to have a plain object with a null prototype and the sendMessage/onMessage properties set as property descriptors. + * [timothy] I agree. + * [rob] Is this object+prototype feasibly implementable? + * [oliver] I would have to ask Devlin. + * [timothy] I think it would be implementable. + * [rob] In Firefox there are no implementation constraints here. + +[PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API + + * [timothy] Proposal for public suffix list API. Something we all agreed on doing. + * [rob] I left review already. This proposal is very detailed and includes the background context and use cases that eases the evaluation of the proposal. + * [rob] The proposal suggests getVersion(), should we expose it? + * [oliver] There is no official version, basically a timestamp. When I asked PSL maintainers they stated that there is no official version system but that they are willing to consider one (and actually keen to add it given previous requests). + * [rob] An easy one would be a timestamp. + * [oliver] No strong opinions either way. + * [rob] The proposed batch-query method currently returns multiple domains (with private and without private suffixes). I'm inclined to return just one domain (private or non-private). If an extension is interested in both, it could call the API twice, with a different option. + * [oliver] Sounds reasonable. + * [timothy] That would be the reasonable approach. + * [simeon] Is this method sync? + * [rob] All methods are async unless there's a compelling reason to make them sync. The proposal has a second method to run multiple queries in bulk (“batch”). + * [rob Proposal suggests automatically encoding domains in unicode format rather than in Punycode. I'm inclined to default to the canonicalized version of the domain (Punycode). + * [timothy] Depends on use case. Would it be displayed to the user? Depending on use case. + * [rob] So you would be in favor of an option to encode as unicode. + * [timothy] I'm in a favor of an opt-in to support these case. + * [rob] The proposal currently specifies an opt-out option. + * [timothy] I'm fine either way, depending on use cases. + * [oliver] The tabs API uses punycode encoding. + * [rob] tab.url is a URL whose canonical representation is punycode. It would be surprising if a canonicalized input host name is transformed to unicode. Agree to matching tabs. + * [timothy] I also prefer to match existing APIs. + +[PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API + + * [timothy] Rob and Oliver have approved it. + * [rob] I left some comments earlier, saw that the PR was updated. Will check that and probably merge after that. Any more comments Aaron? + * [aaron] No. Thanks for getting through this proposal. + * [rob] Is there an implementation of this in Chrome? + * [aaron] First part was implemented in Chrome (131), second part has not. + * [rob] There is also work in progress on the first part in Firefox, the second one not. Second part (getPartitionKey) is however relatively trivial to implement. + * [timothy] Safari does not have partitionKey in the cookies API; once we implement that we would likely add support for this too. + + [PR 675](https://github.com/w3c/webextensions/pull/675): Add developer tools contexts in runtime.getContexts() proposal + + * [mukul] When we discussed this last time, there needs to be another review before merge. Waiting for Oliver? + * [oliver] I'll give it another review. + * [rob] I'll give it another pass too. + * [timothy] I read through this one and it looks good to me in its current state. + +[Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024 + + * [timothy] TPAC is two weeks from now: Sept 23-27. Meetings on the first two days and last two days with breakout sessions in the middle. I've reached out to the Browser Tools & Testing chair to schedule a webdriver sync but haven't heard back yet. So far most of the cross-group topics we've discussed have been related to testing. Would be useful to discuss WPT and potential WebDriver changes needed. + * [timothy] Simeon and I are working on rough drafts of agendas. + * [simeon] I expect that we can share them in the WECG issue and Matrix room. + * [timothy] There will be a remote option, for those who are not able to join in person. Probably Zoom like previous years. Pay attention to the official TPAC schedule. + * [rob] By official TPAC schedule, you meant the agenda item, right? + * [oliver] We can also post to the Matrix chat. + * [timothy] Any other topics? Perennial topic is specification. We're doing a decent job now of creating proposals for future changes. Always hard to document retroactively. In San Diego we also discussed the possibility of converting the Community Group (CG) into a Working Group (WG). If there's any progress there, please bring updates to TPAC. One point we've heard feedback on internally is that we need a starting point spec for consideration to create a WG. We would need a more concurrent specification if we want to explore a WG. + * [simeon] Very keen to make progress on a specification. + * [oliver] I still have an open PR about a content script specification. + * [timothy] Testing is a good way to tie this back to a specification. + +The next meeting will be on [Thursday, September 26th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=66f4a400,384). This is in the week of TPAC 2024, September 23 until 27 ([issue 659](https://github.com/w3c/webextensions/issues/659)). diff --git a/_minutes/README.md b/_minutes/README.md index 98df420b..90dbbe0c 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,24 +10,26 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2024-09-12 at 8 AM PDT = https://everytimezone.com/?t=66e22f00,384 - 2024-09-23 until 2024-09-27 = TPAC 2024 ([issue 659](https://github.com/w3c/webextensions/issues/659)) ([TPAC 2024 Coordination](https://github.com/w3c/webextensions/wiki/TPAC-2024-Coordination)) - 2024-09-26 at 8 AM PDT = https://everytimezone.com/?t=66f4a400,384 +- 2024-10-10 at 8 AM PDT = https://everytimezone.com/?t=67071900,384 ## Past meetings +* 2024-09-12 ([minutes](2024-09-12-wecg.md)) +* 2024-08-29 ([minutes](2024-08-29-wecg.md)) * 2024-08-15 ([minutes](2024-08-15-wecg.md)) * 2024-08-01 ([minutes](2024-08-01-wecg.md)) * 2024-07-18 ([minutes](2024-07-18-wecg.md)) * 2024-07-04 ([minutes](2024-07-04-wecg.md)) -* 2024-06-20 ([minutes](2024-06-20-wecg.md)) -* 2024-06-06 ([minutes](2024-06-06-wecg.md))
All past meeting notes **2024** +* 2024-09-12 ([minutes](2024-09-12-wecg.md)) +* 2024-08-29 ([minutes](2024-08-29-wecg.md)) * 2024-08-15 ([minutes](2024-08-15-wecg.md)) * 2024-08-01 ([minutes](2024-08-01-wecg.md)) * 2024-07-18 ([minutes](2024-07-18-wecg.md))