Skip to content

Latest commit

 

History

History
121 lines (92 loc) · 9.53 KB

2024-07-04-wecg.md

File metadata and controls

121 lines (92 loc) · 9.53 KB
Raw

WECG Meetings 2024, Public Notes, Jul 4

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

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

Agenda: discussion in #644, 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)
    • TPAC
  • Triage (15 minutes)
  • Timely issues (10 minutes)
  • Check-in on existing issues (20 minutes)
    • Issue 624: Proposal: getLeafTarget() method (creator, requestor: @polywock)
    • Issue 536: Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection) (creator, requestor: @hackademix)

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Rishik Ramena (Microsoft)
  3. Giorgio Maone (NoScript, Tor)
  4. Oliver Dunk (Google)
  5. Rémi Pujo (Dashlane)
  6. Carlos Jeurissen (Jeurissen Apps)
  7. Timothy Hatcher (Apple)
  8. Tomislav Jovanovic (Mozilla)
  9. Maxim Topciu (AdGuard)
  10. Mukul Purohit (Microsoft)

Meeting notes

Announcement: TPAC 2024

  • [timothy] Simeon was able to talk to folks at W3C and get us on the schedule. We are now on the calendar for TPAC, 2 slots on on Monday. All day on Tuesday but switching rooms. Thursday two different timeslots, and Friday all day.
  • [rob] Do we already have an issue?
  • [timothy] I or Simeon will create an issue.
  • [rob] For context, TPAC is an annual event where W3C members gather to discuss standarization topics. We participated last year and are planning to meet again this year. This year it is at Anaheim, CA, USA (near Los Angeles).
  • [oliver] Patrick and I are planning to attend, Devlin probably too.
  • [timothy] Safari team should all be there.
  • [tomislav] On Mozilla's side me, Rob, Simeon.

Issue 645: Inconsistency: Commands API support for Cmd+Alt on Apple OSs

  • [rishik] I found an inconsistency .. There is no AltGr key on mac. Cmd+Alt is disallowed in Chrome, but accepted in Safari and Firefox. Should Cmd+Alt be allowed?
  • [timothy] We support Cmd+Alt. I thought that it was odd in other Chrome. Note that Ctrl maps to Cmd on mac for compatibility.
  • [rishik] Cmd maps to Ctrl, not the other way around, at least in Chrome and Edge.
  • [timothy] That sounds right.
  • [oliver] I don't have more context. I'll check internally and follow up.
  • [rob] Since Firefox and Safari already support this, we can put the supportive labels on the issue, and the follow-up label for Chrome.

Issue 646: userScripts API: method to get matching ids for a URL (@tophf)

  • [rob] Proposal to get the IDs of the matching scripts for a URL. I wondered whether a URL is sufficiently precise description (e.g. it does not match about:blank), which toph affirmed.
  • [tomislav] What is the point of allFrames?
  • [rob] I suppose that it is to match scripts which have allFrames set or not.
  • [oliver] Skimmed the issue now; Seems like an interesting idea.
  • [rob] Suggest reading and responding async on the issue.
  • [timothy] Since we don't support the userScripts API yet, I don't have any feedback to offer yet.

Issue 647: Shadow DOM problems for extensions (@lapcat)

  • [rob] Feature request to interact with DOM within shadow DOM. Request to make it easier to add styles, register events, querySelector and Mutation Observers. I commented that querySelector integration existed before but was dropped due to implementation complexity. Any way to be notified of new shadow roots would be appreciated, according to the requester.
  • [timothy] This does seem like something the web platform should address, but they likely don't see it as needed since they don't have the ability to dig into closed roots like the extension API
  • [oliver] Even if an API were to be added to the web, it would probably only address open shadow DOM, not closed ones.
  • [rob] Bare minimum to support the request, is enumeration of shadow roots and an observer for new shadow roots. Enumeration is already possible but only for open shadow roots and requires filtering all elements.
  • [oliver] I imagine that we could support a method to efficiently query shadow roots.

Issue 648: Inconsistency: identity.clearAllCachedAuthTokens API availability (@twschiller)

  • [tomislav] clearAllCachedAuthTokens
  • [rob] The identity API consists of two parts, launchWebAuthFlow, which delegates credential handling to a third party website. The other part is getAuthToken, etc, where credentials are managed by the browser. Firefox doesn't support this.
  • [rob] identity.removeCachedAuthToken was requested before in Firefox, which I closed with an explanation at https://bugzilla.mozilla.org/show_bug.cgi?id=1888889#c2
  • [mukul] We don't support getAuthToken, and probably also not this API either. I took a note to review and update our documentation.
  • [tomislav] Should we close this issue since it is Chrome-specific at this point?
  • [oliver] We already support the API and there is nothing to change for us. Agree with closing the issue.
  • [mukul] Does Firefox have any plans to support getAuthToken ?
  • [rob] No. It is very Google (account) specific.
  • [timothy] We don't have plans to support this either.

Issue 649: Add getKeys() proposal (@oliverdunk)

  • [oliver] polywock proposed a getAllKeys method to the storage API. I created a concrete proposal. We just need to decide on the name. Jackie suggested keys() to match other web platform APIs. I think that getKeys is a better fit due to the existing naming conventions in extension APIs.
  • [rob] I'm in favor of getAllKeys() or getKeys(), for the reasons Oliver mentioned.
  • [timothy] While I'd like to be able to drop get prefix, for consistency we should continue using the “get” prefix convention for now.

Issue 624: Proposal: getLeafTarget() method (creator, requestor: @polywock)

  • [timothy] Sounds familiar to the other shadow DOM issue? (Issue 647)
  • [rob] Unlike the other request, there is no implementation complexity concern - browsers already capture events and filter nodes within shadow DOM. I'm in favor of supporting this method.
  • [tomislav] Sounds like a good idea.
  • [timothy] Sounds like a good idea.
  • [rob] Chrome?
  • [oliver] I'll follow up internally and respond. I wonder whether we can add an option to the event.composedPath method on the web platform, e.g. an includeShadowRoots option for extension only.

Issue 536: Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection) (creator, requestor: @hackademix)

  • [giorgio] Google expressed opposition to this API. The requested capability is however important, not just to me but also other extensions. If you really want to use globalParams proposal it would support my use case, as long as it is configurable per tab. It'd be limited to the ISOLATED world only though.
  • [oliver] One consideration was that we already had an implementation in globalParams and the ability to offer the feature quick.
  • [giorgio] Concerned about approaching MV2 deprecation in Chrome, an.
  • [oliver] Thinking that MV2 and MV3 do not differ significantly in this capability.
  • [giorgio] we've got work-arounds on MV2 which are not available on MV3.
  • [rob] Your work-around is to use sync XHR and send a response with webRequest. Would declarativeNetRequest.updateSessionRules + tabIds option be a suitable work-around?
  • [rob] The globalParams feature offers a capability that is not only desired by content scripts; it can also be useful to the background scripts.
  • [timothy] Thought is that the runtime namespace could make more sense than the scripting namespace.

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