forked from w3c/webextensions
-
Notifications
You must be signed in to change notification settings - Fork 0
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 w3c#685 from w3c/meeting-2024-09-12
Publish minutes of 2024-09-12 meeting
- Loading branch information
Showing
2 changed files
with
163 additions
and
3 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,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)). |
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