|
| 1 | +# WECG Meetings 2024, Public Notes, Sep 12 |
| 2 | + |
| 3 | + * Chair: Timothy Hatcher |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=66e22f00,384 |
| 7 | +Call-in details: [WebExtensions CG, 12th September 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240912T080000/) |
| 8 | +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) |
| 9 | + |
| 10 | + |
| 11 | +## Agenda: [discussion in #682](https://github.com/w3c/webextensions/issues/682), [github issues](https://github.com/w3c/webextensions/issues) |
| 12 | + |
| 13 | +The meeting will start at 3 minutes after the hour. |
| 14 | + |
| 15 | +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. |
| 16 | + |
| 17 | + * **Announcements** (2 minutes) |
| 18 | + * **Triage** (15 minutes) |
| 19 | + * [Issue 683](https://github.com/w3c/webextensions/issues/683): Feature request. More granular Extension's hotkeys scope |
| 20 | + * [Issue 684](https://github.com/w3c/webextensions/issues/684): Feature request: enabled user gestures for omnibox events |
| 21 | + * **Timely issues** (10 minutes) |
| 22 | + * [PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() |
| 23 | + * [PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() |
| 24 | + * [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API |
| 25 | + * [PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API |
| 26 | + * [PR 675](https://github.com/w3c/webextensions/pull/675) : Proposal : Add developer tools contexts in runtime.getContexts() |
| 27 | + * **Check-in on existing issues** (20 minutes) |
| 28 | + * [Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024 |
| 29 | + |
| 30 | + |
| 31 | +## Attendees (sign yourself in) |
| 32 | + |
| 33 | + 1. Oliver Dunk (Google) |
| 34 | + 2. Rob Wu (Mozilla) |
| 35 | + 3. Timothy Hatcher (Apple) |
| 36 | + 4. Aaron Selya (Google) |
| 37 | + 5. Giorgio Maone (Tor, NoScript) |
| 38 | + 6. David Johnson (Apple) |
| 39 | + 7. Rémi Pujo (Dashlane) |
| 40 | + 8. Sohail Rajdev (Microsoft) |
| 41 | + 9. Solomon Kinard (Google) |
| 42 | + 10. Mukul Purohit (Microsoft) |
| 43 | + 11. Simeon Vincent (Mozilla) |
| 44 | + 12. Kiara Rose (Apple) |
| 45 | + 13. Jordan Spivack (Capital One) |
| 46 | + 14. Tim Heflin (Keeper) |
| 47 | + 15. Carlos Jeurissen (Jeurissen Apps) |
| 48 | + |
| 49 | + |
| 50 | +## Meeting notes |
| 51 | + |
| 52 | +[Issue 683](https://github.com/w3c/webextensions/issues/683): Feature request. More granular Extension's hotkeys scope |
| 53 | + |
| 54 | + * [oliver] As I understand it, it is like commands that we have today, except limited to when specific URLs are being displayed. |
| 55 | + * [timothy] Not necessarily focused on the page, but also including when the tab is being hovered on or active? |
| 56 | + * [oliver] I think that it would be useful to clarify. |
| 57 | + * [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. |
| 58 | + * [oliver] Also interested in complexity, and shortcut conflicts. |
| 59 | + * [timothy] Commands are global, having controls when they are active would be useful. |
| 60 | + * [oliver] I think that I'd be in favor of limiting shortcuts to one extension. |
| 61 | + * [rob] Extensions can already do this by limiting shortcut handling to when specific conditions are met. |
| 62 | + * [timothy] There could still be confusion when multiple extensions register it. |
| 63 | + * [rob] I'm not opposed to the capability request, but would like some more detailed description of desired behavior and then discuss the specifics. |
| 64 | + * [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. |
| 65 | + |
| 66 | +[Issue 684](https://github.com/w3c/webextensions/issues/684): Feature request: enabled user gestures for omnibox events |
| 67 | + |
| 68 | + * [rob] Sounds reasonable. |
| 69 | + * [oliver] Devlin added a comment that we are supportive from the Chrome side. |
| 70 | + * [oliver] Jackie asked about activeTab. |
| 71 | + * [rob] Why not active tab? User is clearly invoking extension functionality. |
| 72 | + * [oliver] Maybe onInputEntered is okay, but I was thinking of other events. |
| 73 | + * [rob] So you would be okay with granting activeTab when the user presses enter, but not when the user is just typing. |
| 74 | + * [simeon] Granting onInputEntered could be racy as you get a grant for a short moment before triggering a navigation. |
| 75 | + * [david] No different from interaction with an extension button. |
| 76 | + * [oliver] I think it is common to navigate to a new page when you press Enter from the omnibox. |
| 77 | + * [rob] Going back, I'm okay with granting user gestures in onInputEntered. Also okay with granting activeTab. |
| 78 | + * [timothy] I agree. |
| 79 | + * [oliver] There is an open CL as well. |
| 80 | + * [rob] Does that CL also cover activeTab? |
| 81 | + * [oliver] I don't think so. |
| 82 | + * [rob] Could you get it clarified? |
| 83 | + * [oliver] Yes. We would likely decouple it from the current CL though. |
| 84 | + * [rob] If not supported it could be a simple documentation fix, otherwise we could all consider implementing activeTab. |
| 85 | + * [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. |
| 86 | + |
| 87 | +[PR 678](https://github.com/w3c/webextensions/pull/678): Proposal: dom.execute() |
| 88 | + |
| 89 | + * [timothy] I haven't reviewed the proposal yet. |
| 90 | + * [rob] I left a review. This is a follow-up to our San Diego meeting, and nothing too surprising. We can continue async here. |
| 91 | + |
| 92 | +[PR 679](https://github.com/w3c/webextensions/pull/679): Proposal: dom.createPort() |
| 93 | + |
| 94 | + * [timothy] This PR is about communicating between multiple worlds, goes hand in hand with the dom.execute proposal(). |
| 95 | + * [oliver] I saw a comment about worldId. |
| 96 | + * [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. |
| 97 | + * [oliver] Is there a potential risk of one extension leaking the prototype? |
| 98 | + * [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. |
| 99 | + * [timothy] I agree. |
| 100 | + * [rob] Is this object+prototype feasibly implementable? |
| 101 | + * [oliver] I would have to ask Devlin. |
| 102 | + * [timothy] I think it would be implementable. |
| 103 | + * [rob] In Firefox there are no implementation constraints here. |
| 104 | + |
| 105 | +[PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API |
| 106 | + |
| 107 | + * [timothy] Proposal for public suffix list API. Something we all agreed on doing. |
| 108 | + * [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. |
| 109 | + * [rob] The proposal suggests getVersion(), should we expose it? |
| 110 | + * [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). |
| 111 | + * [rob] An easy one would be a timestamp. |
| 112 | + * [oliver] No strong opinions either way. |
| 113 | + * [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. |
| 114 | + * [oliver] Sounds reasonable. |
| 115 | + * [timothy] That would be the reasonable approach. |
| 116 | + * [simeon] Is this method sync? |
| 117 | + * [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”). |
| 118 | + * [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). |
| 119 | + * [timothy] Depends on use case. Would it be displayed to the user? Depending on use case. |
| 120 | + * [rob] So you would be in favor of an option to encode as unicode. |
| 121 | + * [timothy] I'm in a favor of an opt-in to support these case. |
| 122 | + * [rob] The proposal currently specifies an opt-out option. |
| 123 | + * [timothy] I'm fine either way, depending on use cases. |
| 124 | + * [oliver] The tabs API uses punycode encoding. |
| 125 | + * [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. |
| 126 | + * [timothy] I also prefer to match existing APIs. |
| 127 | + |
| 128 | +[PR 581](https://github.com/w3c/webextensions/pull/581): Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API |
| 129 | + |
| 130 | + * [timothy] Rob and Oliver have approved it. |
| 131 | + * [rob] I left some comments earlier, saw that the PR was updated. Will check that and probably merge after that. Any more comments Aaron? |
| 132 | + * [aaron] No. Thanks for getting through this proposal. |
| 133 | + * [rob] Is there an implementation of this in Chrome? |
| 134 | + * [aaron] First part was implemented in Chrome (131), second part has not. |
| 135 | + * [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. |
| 136 | + * [timothy] Safari does not have partitionKey in the cookies API; once we implement that we would likely add support for this too. |
| 137 | + |
| 138 | + [PR 675](https://github.com/w3c/webextensions/pull/675): Add developer tools contexts in runtime.getContexts() proposal |
| 139 | + |
| 140 | + * [mukul] When we discussed this last time, there needs to be another review before merge. Waiting for Oliver? |
| 141 | + * [oliver] I'll give it another review. |
| 142 | + * [rob] I'll give it another pass too. |
| 143 | + * [timothy] I read through this one and it looks good to me in its current state. |
| 144 | + |
| 145 | +[Issue 659](https://github.com/w3c/webextensions/issues/659): WECG at TPAC 2024 |
| 146 | + |
| 147 | + * [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. |
| 148 | + * [timothy] Simeon and I are working on rough drafts of agendas. |
| 149 | + * [simeon] I expect that we can share them in the WECG issue and Matrix room. |
| 150 | + * [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. |
| 151 | + * [rob] By official TPAC schedule, you meant the agenda item, right? |
| 152 | + * [oliver] We can also post to the Matrix chat. |
| 153 | + * [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. |
| 154 | + * [simeon] Very keen to make progress on a specification. |
| 155 | + * [oliver] I still have an open PR about a content script specification. |
| 156 | + * [timothy] Testing is a good way to tie this back to a specification. |
| 157 | + |
| 158 | +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)). |
0 commit comments