- Chair: Timothy Hatcher
- Scribes: Simeon Vincent
Time: 8 AM PDT = https://everytimezone.com/?t=67071900,384 Call-in details: WebExtensions CG, 10th October 2024 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat
Agenda: discussion in #697, github issues
The meeting will start at 3 minutes after the hour.
See issue 531 for an explanation of this agenda format.
- Announcements (12 minutes)
- Triage (15 minutes)
- Issue 698: MessageFormat 2 support
- Issue 699: Allow object as second i18n.getMessage() argument
- Issue 701: Block extension from specific hosts
- Issue 702: Namespace for experimental APIs
- Issue 703: State in background scripts, synchronously available across restarts
- Issue 707: Request for Comments: Extension Performance
- Timely issues (10 minutes)
- Check-in on existing issues (10 minutes)
- Oliver Dunk (Google)
- David Johnson (Apple)
- Timothy Hatcher (Apple)
- Simeon Vincent (Mozilla)
- Casey Garland (Capital One)
- Carlos Jeurissen (Jeurissen Apps)
- Mukul Purohit (Microsoft)
- Aaron Selya (Google)
- Jordan Spivack (Capital One)
- Maxim Topciu (AdGuard)
- Solomon Kinard (Google)
- Tim Heflin (Keeper)
- [timothy] Second day we continued discussions on experimental APIs and held an issue prioritization session for small issues to help align browser vendor next steps with community interest. After that we had a lead session to discuss continuing to evolve the group. After the power outage, we did a backlog cleanup session and got through around 12 issues.
- [timothy] Wednesday was mostly breakout sessions. We didn't have any scheduled related to our group, but other breakout sessions were amazing. My favorite was the one about how we do the internet on the moon.
- [timothy] On Thursday we had our regular WECG meeting where we did a deep dive on Message Format 2 – what the format could look like, how we might integrate it into extensions, state of the standard and the fact that it should be available soon. It's currently polyfilled in Firefox. It's pretty impressive that we can potentially quickly adopt a message format with support for pluralization and other useful features.
- [timothy] Apple to create a proposal for declarative cosmetic rules. Later we attended a session with the browser tools and testing meeting WG to discuss how we'd tackle testing extensions in WPT. BiDi is the way forward, but we will likely need a compatible implementation with the current WebDriver system. After that we had a discussion about asynchronous background startup and state restoration. No firm conclusions from that discussion, but there was a broad range of options discussed.
- [oliver] Would be good to get a concrete proposal together. A lot of ideas were discussed, but we should try to dig into and advance one.
- [timothy] Next we discussed permissions. There are a number of scenarios where you don't know that you need a permission. One example was needing to provide your own deny list. Conversation was spread, so I'm light on details. That was it for Thursday.
- [timothy] On Friday we had a large morning session on testing. This discussion got into more details how how we integrate into WPT. After the Browser Tools and Testing sync, we discussed more details about transferring the extension over between test runner and test client. After that we did another 90 minute session for issue triage. I left after this, but there was one final sync on browser tools and testing. Aspects discussed included whether tests should be single file solutions, etc.
- [oliver] We had a final sync to discuss next steps on the spec. Picked out a couple of examples – small APIs where we felt we could specify common behavior.
- [timothy] Makes sense to focus on the smaller pieces. It was a very productive week.
- [simeon] Just want to say that I appreciate the way that we all work together.
- [timothy] Also appreciate how we run our meetings. I found the queue systems a bit difficult to work with.
Issue 698: MessageFormat 2 support
- [timothy] This captures details that we discussed during the meeting. Looks like supportive labels are already applied.
Issue 699: Allow object as second i18n.getMessage() argument
- [timothy] Came out of the messageFormat 2 discussion. Would be useful to provide an object rather than just an array. Would be nice to have named parameters. Allows for semantic names, more flexibility in how strings may be rearranged.
- [oliver] Had some discussion with Devlin. We are generally supportive of being able to specify the names of substitutions. Worth noting that other proposals conflict with this one. For example, providing a second parameter for a substitution language – how would that conflict with the ability to specify a language dictionary. Bears further discussion.
- [timothy] Again, I vote for live objects.
- [timothy] Was everyone supportive fo this idea? Please check labels.
- [oliver] Would maybe go neutral until we have a more updated proposal.
- [timothy] Could you add a comment about the discussion you had?
- [oliver] Can do.
Issue 701: Block extension from specific hosts
- [timothy] If an extension requests access to all sites, there's no way to remove specific sites. If a host permission is declared in the manifest, there's no way to withdrawal it. The issue crater is essentially proposing a blocklist to add host permission patterns to block. We could support this, but curious for others thoughts.
- [oliver] I believe we've had concerns in the past, but don't recall details. Will need to follow up
- [timothy] Don't think every extension will use it, but extensions that want to block content on specific hosts would find it useful.
- [carlos] There were previous proposals to do this in the manifest. This is dynamic. Potentially less secure, but covers more use cases.
- [timothy] I don't have much concern since this would be reducing permissions rather than increasing them.
- [oliver] Might need to think through how this is presented to users. For example, if extension blocks access to bank.com users might assume that bank.com is safe, but the extension could still access coordinating sites.
- [casey] As a dev, if we could use it we would. We want to make sure we never track users on a number of sites. I expect we would enthusiastically use this.
- [timothy] Definitely worth considering.
- [simeon] We don't have to show every detail to the user. Even if there's no UI informing users that the extension is doing the right thing, good actors should use it
- [timothy] There would at least be a visual indication in Safari as the extension's action is grayed out when it doesn't have access on the current page.
Issue 702: Namespace for experimental APIs
- [timothy] In short, we were all supportive during TPAC but we didn't come up with a name because naming is hard. Some proposed names were thrown around and were captured in the notes but not the issue. I think in the room at the time “unstable” was a favorite. I think Chrome is to use this first?
- [oliver] I believe Devlin is going to create a proposal in the next few weeks.
Issue 703: State in background scripts, synchronously available across restarts
- [timothy] In addition to session storage which is async, this would give extensions some immediate background data on startup. We were supportive of this, as were others I believe.
- [oliver] When we were talking earlier about non-persistent lifetimes, this is one of the ideas that came up. Would be good to create a proposal for it.
- [timothy] Add labels when you can.
Issue 707: Request for Comments: Extension Performance
- [timothy] This goes into details about how devtools is spread out across many different contexts. Could have a unified place to gather performance, console logging, cross-context issues.
- [oliver] There was a brief conversation in Matrix about this asking if we were interested in performance. Nothing specific in mind on how to action this. We want to measure extensions aren't negatively impacting site performance, but no ideas off the top of my head.
- [jordan] This was me. Scope could be small or wider ranging, depending on how in depth you want to get. Seems like there's room for tooling improvements.
- [timothy] Definitely gotten feedback about the difficulty of debugging across many different contexts. For folks more familiar with web debugging, this can be difficult to work with.
- [simeon] Might be worth noting that we can't lean on motivated developers to explore ideas here because extensions can't debug extensions like they can websites.
PR 690: Proposal: add cookies.removeAll() method
- [timothy] Largely a reminder for me. This PR introduces a .removeAll() method. Aaron recently pushed a couple updates.
- [aaron] Yep, thanks for the feedback. Expect that this will get resolved soon once Rob gets back from vacation. We seem well aligned, just need to work through small details and clarifications.
- [timothy] Requirement is now to have a top level url, right?
- [aaron] yes, and I think you suggested that should be safe. Might end up going away from my initial idea of having a top level site in a parameter and allow just a partition key with just a top level site. The site would be enclosed in the partition key.
- [timothy] I think my preference would be to match where top level site is normally, rather than promoting it to the top for just this method. I think that's in line with Rob's feedback. I'll take another pass.
PR 679: Proposal: dom.createPort()
- [timothy] There's been a decent amount of discussion in the last two weeks on this. This is relevant to the dom.execute() proposal. I want to go back over and add additional comments, I'd encourage others to as well. Would like to keep the momentum from TPAC going and finish these out.
- [simeon] Would it be useful to have an example for migrating off postmessage? Maybe for an MDN content update?
- [timothy] There's a decent example in the proposal. Not exactly what you were describing for migrating from A to B. Would definitely be good to have that on MDN.
PR 678: Proposal: dom.execute()
- [timothy] This is really in support of dom.createPort(), but can also be used for other purposes so you don't have to message to your background script all the time. Doesn't require creating a script tag in the main world.
Issue 601: Proposal: StorageArea.getKeys()
- [timothy] Recently had someone implement this in WebKit. That's two implementations. Wanted to check if Firefox is still interested.
- [simeon] I expect so, but don't want to commit the eng folks to work without their input.
- [timothy] Should ship in Safari Tech Preview soon.
PR 569: Proposal: i18n-system-languages
- [timothy] I've approved, could use approval from another vendor. This is Carlos' proposal. He took the time to implement it in WebKit during TPAC. I think he may have done another implementation as well?
- [carlos] Yes, I have a patch for Firefox. It still needs a test, but that should be it.
- [timothy] Anything outstanding that's blocking the proposal?
- [carlos] Nothing that I'm aware of.
- [timothy] Would be good to get feedback from Chrome and Firefox, especially with a Firefox proposal pending.
Open discussion
- [simeon] I'm working on a podcast related to extensions. If anyone here is interested, I'd love to sit down and chat about thoughts or opinions about the platform, proposals, the ecosystem, etc. Feel free to reach out on Matrix or elsewhere 🙂
The next meeting will be on Thursday, October 24th, 8 AM PDT (3 PM UTC).