Skip to content

Latest commit

 

History

History
143 lines (120 loc) · 10.6 KB

2024-08-15-wecg.md

File metadata and controls

143 lines (120 loc) · 10.6 KB
Raw

WECG Meetings 2024, Public Notes, Aug 15

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=66bd4500,384 Call-in details: WebExtensions CG, 15th August 2024 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #667, github issues

The meeting will start at 3 minutes after the hour.

See issue 531 for an explanation of this agenda format.

  • Announcements (2 minutes)
  • Triage (15 minutes)
    • Issue 668: Proposal: Add ancestorMatches/excludeAncestorMatches in scripting API
    • Issue 669: Proposal: Incognito parameter in userScripts API
    • Issue 670: Exposing developer tools contexts in runtime.getContexts() API
  • Timely issues (10 minutes)
  • Check-in on existing issues (20 minutes)

Attendees (sign yourself in)

  1. Timothy Hatcher (Apple)
  2. Oliver Dunk (Google)
  3. Rob Wu (Mozilla)
  4. David Johnson (Apple)
  5. Tamer Temizer (eyeo)
  6. Solomon Kinard (Google)
  7. Mukul Purohit (Microsoft)
  8. Tomislav Jovanovic (Mozilla)
  9. Maxim Topciu (AdGuard)
  10. Sohail Rajdev (Microsoft)
  11. Simeon Vincent (Mozilla)
  12. Aaron Selya (Google)
  13. Tim Heflin (Keeper)

Meeting notes

Issue 668: Proposal: Add ancestorMatches/excludeAncestorMatches in scripting API

  • [timothy] Request from gorhill to exclude/match content script based on ancestor frames, not just the frame URL. For ad blocking purposes where uBlock Lite (...). Rob proposed location.ancestorOrigins.
  • [rob] location.ancestorOrigins + ability to retrieve dynamically configurable settings synchronously would be an appropriate alternative to the requested capability. If there are major use cases that cannot be addressed otherwise I'd be willing to consider an addition to the API.
  • [timothy] Main advantage of including it in the API is avoiding injection where not neede.
  • [oliver] Hesitant, adding more and more conditions to injection.
  • [rob] That's why I am interested in use cases - if common & frequent need, then a dedicated property makes sense, otherwise I prefer location.ancestorOrigins + sync preference access makes sense.
  • [timothy] Makes sense. I don't know about WebKit's stance on location.ancestorOrigins, but I can look it up.
  • [david] Safari seems to already support location.ancestorOrigins.
  • [timothy] Safari position - neutral towards this API.
  • [oliver] Neutral for now too.
  • [simeon] Neutral too; though declarative APIs feel useful in general. And CSS cannot use the check.
  • [timothy] Good point - that is why I was initially in favor too, because declaratively we can minimize injection.
  • [rob] There are alternatives for CSS, like using a very specific class name in combination with :not().
  • [timothy] Next step is to see use cases.

Issue 669: Proposal: Incognito parameter in userScripts API

  • [timothy] Sounded familiar, in the context of content scripts.
  • [oliver] #611. On that note, at Chrome we are supportive of exposing runtime.inIncognitoContext in user scripts.
  • [rob] Additional context: erosman reached out and I asked them to open a WECG issue. Use case is to declare whether scripts can or cannot run in private or non-private browsing mode.
  • [timothy] That seems more useful. Tentatively supportive.
  • [rob] We'd be supportive of cookieStoreId. Potential issue is that their potential values is non-standard across browsers. Boolean or enum for incognito?
  • [tomislav] Could provide constants for known values to abstract exact values used.
  • [oliver] I'll follow up, but this feels acceptable.
  • [rob] Boolean is slightly strange, because it is a tri-state: run in incognito only, run in non-incognito only, or either. On the other hand, “incognito” is a boolean property in many of our extension APIs, and we don't expect more states, so we can use true / false / null.
  • [simeon] Feels odd to have a single bool try to represent that. Two bools seem like they would better match my expectations for explicitly declaring browsing modes. Preference for enum here.
  • [timothy] Fine with bool. Should consider use in user scripts and content scripts.
  • [rob] I agree. Incognito flag also makes sense in the regular content script APIs.

Issue 670: Exposing developer tools contexts in runtime.getContexts() API

  • [timothy] Seems fine to me. Wondering about Chrome's perspective on this.
  • [oliver] Generally makes sense. Exposing in general makes sense. In the case of the options page we considered a dedicated options_ui type, but used tab because we did not anticipate much use.
  • [timothy] Consolidating all proposed types as one would make sense.
  • [oliver] Can also filter by URL, so extension authors should have an effective way to target based on context.
  • [rob] These three types are very specific. Unless there's a clear need, would prefer to consolidate.
  • [mukul] Firefox's perspective?
  • [rob] Supportive of the request. When getContext() was designed in the WECG, we also talked about other types such as content scripts. A concern was the number of contexts, but in the devtools case I expect relatively few matching contexts.
  • [tomislav] Different APIs for different purposes. We can cover the general case here and allow devs to implement additional filtering as needed.
  • [timothy] Devs will need to implement additional targeting for devtools pages based on the context they're debugging.
  • [rob] Devtools pages are extension-defined, if extensions really want to identify specific devtools page types, they can choose file names.
  • [oliver] Potential breaking change since Chrome currently returns them as the “TAB” type.
  • [rob] And that is why Firefox does currently not return them.
  • [timothy] Oliver to follow up on Chrome status.
  • [mukul] Next step after Chrome's feedback is that we update the existing getContexts proposal in the repo.

Issue 310: New API: Open Shortcut Setting

  • [timothy] Someone has submitted a patch to Firefox related to this issue.
  • [rob] First of all, whether we agree on the functionality of the API, and secondly the shape of the API.
  • [timothy] I think that the commands namespace makes sense.
  • [oliver] Discoverability of the runtime namespace is nice.
  • [timothy] Can you assign a command to the action button?
  • [rob] Extensions can declare a command to trigger the action button.
  • [timothy] And the user?
  • [tomislav] No, users cannot.
  • [rob] When the API is called, I'm in favor of focusing the part of the shortcut management page specific to the calling extension.
  • [timothy] For sure.
  • [rob] Since the API method does not have much functionality without a defined command, I agree with putting it under the commands namespace.
  • [timothy] In favor of putting it under commands.
  • [simeon] I believe that Chrome enables you to set a shortcut for an action even if there is no command.
  • [oliver] I think that you are right.
  • [rob] I don't see a conflict between this observation and putting it in the commands namespace. Extensions unaware of shortcuts won't call this method. And if they want to call this, then they can simply add “commands”:{} in manifest.json.
  • [timothy] Makes sense.
  • [oliver] I'll follow up with Chrome.
  • [oliver] openShortcuts sounds like a strange name.
  • [timothy] In Safari it would not be a page, but a settings section.
  • [rob] openShortcutsManagementUI, openShortcutsPage. … I think that we can bikeshed on the name later once there is agreement on the availability and behavior of the API.

Issue 659: WECG at TPAC 2024

  • [timothy] Time schedule in issue. Wednesday has breakout sessions that we can propose to chat with other groups at TPAC. E.g. testing.
  • [rob] This is an open invitation for everyone to come up with topics. And since we're near other standard groups, topics that overlap with other groups can also benefit from being raised in our TPAC meetings.
  • [timothy] One of the items I mentioned is to solve the postMessage problem. Another one is declarative cosmetic rules. In addition to testing - I think that this is the biggest focus.
  • [rob] On declarative cosmetic rules would be nice to have an API proposal to discuss, because otherwise we would just discuss the capability without progress.
  • [david] We will prepare something.
  • [tomislav] WebAuthn in Seville, do we need follow-ups? I think that Google folks were mainly interested in this.
  • [oliver] I can check with them and see if there are updates. There were changes in Chrome, where extensions were given control over the RP ID.
  • [rob] Anything else?
  • [timothy] Do we need to reach out to anyone else besides wpt?
  • [oliver] WebAuthn was mentioned, but not sure if there is a need for follow-up.
  • [simeon] postMessage - in extensions, does that cover runtime.sendMessage replacement?
  • [timothy] It is specifically about communicating securely between the content script and the main world. runtime.sendMessage is fairly secure today.
  • [simeon] I was thinking of consolidating multiple channels, but that's maybe MV4.
  • [rob] Improving messaging does not need to be specific to a manifest version.
  • [simeon] Thinking of transferables.
  • [timothy] I think that is what Rob is getting at.
  • [rob] Yes. Transferables can avoid unnecessary copies.
  • [simeon] I'm currently working on a document around asynchronous event listeners and user gesture requirements, I expect that to be ready before TPAC.
  • [tomislav] Do the Google folks know how testing is progressing?
  • [oliver] No updates, but I'm interested in working on it as well.
  • [tomislav] I'd like to prepare for the session before TPAC.
  • [timothy] I'd also like to be prepared so we can hit the ground running and make progress.

The next meeting will be on Thursday, August 29th, 8 AM PDT (3 PM UTC)