- Chair: Timothy Hatcher
- Scribes: Rob Wu
Time: 8 AM PDT = https://everytimezone.com/?t=645c3000,384 Call-in details: WebExtensions CG, 11th May 2023 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat
Agenda: github issues
The meeting will start at 3 minutes after the hour.
- Carry-over from previous meetings
- Other new issues
- Open discussion queue (add yourself at the bottom)
- Oliver: runtime.getContexts()
- Check-in on ongoing issues
- None
- Rob Wu (Mozilla)
- Oliver Dunk (Google)
- Tomislav Jovanovic (Mozilla)
- Giorgio Maone (NoScript, Tor)
- Jackie Han (No affiliation)
- Luke Selker (Dashlane)
- Benjamin Bruneau (1Password)
- Mike Selander (1Password)
- Xuezhou Dai (Unaffiliated)
- Timothy Hatcher (Apple)
- Maxim Topciu (AdGuard)
- Simeon Vincent (Unaffiliated)
- David Johnson (Apple)
- Jason Waterman (Mozilla)
- Mukul Purohit (Microsoft)
- Tim Heflin (Keeper)
- Sam Macbeth (DuckDuckGo)
- Kiara Rose (Apple)
- Patrick Kettner (Google)
Issue 258: Per-extension language preferences
- [jackie] I see Safari is supportive to it. But I don't know Chrome and Firefox's position.
- [oliver] I don't know from Google's perspective, need to follow up on it. Simeon, do you know anything from when you were with Google?
- [simeon] When I discussed it with the team, we had reservations with changing the strings the user sees in the extension page. We felt that there were sufficient tools to customize based on the user's preferences.
- [timothy] Yes, had similar concerns with swapping out the extension name to deceive users. On the other hand the extension stores can already review the strings.
- [timothy] Could the browser vendors update the labels with their support status?
- [rob] I'll do that. I'll also add follow-up:chrome to reflect that Oliver wants to follow up with their team before responding.
Issue 353: Support onEnabled event
- [oliver] I haven't been able to reproduce this event. Would personally be interested in an event to transition from non-running to running, but there were reservations about it due to the questions about the usefulness of this.
- [simeon] I'm curious about whether onEnabled vs generic events are more learnable for new developers. Another potential concern of a generic event is the chattiness (receiving events that the extension doesn't care about). Do others have thoughts on subscribing to a category vs. a specific change?
- [timothy] Good point. I'm in favor of separate events. I don't think that event filtering is used as much. The different states are somewhat separate.
- [oliver] Use case I'm thinking of is if the extension wants to show a notification. Now the extension would have to register several events. It would be nice to have a specific event to be able to register for any state.
- [rob] There are several APIs whose state persist across sessions (e.g. declarative APIs, contextMenus, etc.). In these cases, it would be useful to have the ability for the extension to register a handler that initializes the data if needed.
- [rob] Should collect use cases before deciding on the type of event we need.
- [jackie] An event like runtime.onEnabled or onInstalled are okay for devs. No matter what the shape of the API, I think browser vendors should support this capability.
- [rob] Currently the most cross-browser compatible way to support the use case described above (i.e. initializing when needed) is to unconditionally clear/remove the state and initialize (e.g. contextMenus). This is wasteful, especially with event pages.
- [oliver] That may be a longer-term solution; onEnabled may be a shorter term solution. The generic event may be worth exploring
Issue 229: Extension Icon Design for Light/Dark/Custom Theme
- [timothy] I believe Firefox is implementing something here. Safari is considering it. I think we are waiting on status from Chrome.
- [oliver] I think it's safe to say we're supportive.
- [timothy] Haven't had a chance to review Chrome's design doc. Are you doing something similar to Firefox?
- [tomislav] Firefox had an existing implementation where the meaning of dark and light were swapped.
- [rob] We want to go with conventions that are more common on the web platform. With knowledge of the web platform, where the behaviors of light and dark are flipped, inverting that can surprise developers. That's why we are switching to the established patterns (meaning of dark/light), which is consistent with the design doc that Google had shared.
- [timothy] Matches how we approach this on Apple platforms.
- [jackie] Extension is a little different than Web. Similar to action at toolbar, chrome://extensions. Context menu also has an active and inactive state. This will also affect how an icon is displayed.
- [timothy] I think what you're getting at is that a web page's light/dark mode and the browser chrome's light/dark may not match.
- [rob] Oliver mentioned that Chrome is supportive – does this mean supportive of this proposal or the concept in general? Is there active work here?
- [oliver] Supportive, but not on the list of priorities at the moment.
- [timothy] In Safari it will probably be a while before we get to it too.
Issue 384: browsingData RemovalOptions
- [timothy] This is an API that Safari doesn't implement, so I don't have much context.
- [sam] The browsingData is used to delete certain types of storage. Implemented in Chrome and Firefox at the moment, with differences in supported options. Chrome supports including and excluding origins from being deleted. Firefox only supports including origins. Is there an interest in reconciling these differences?
- [timothy] Currently no plans to implement this in Safari.
- [rob] Supportive in Firefox (tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1632796). Patches are welcome.
- [rob] A consideration here is what it means to include or exclude. These days Firefox (and Safari) partition storage by top-level site, so storage is not just keyed by one origin, but double-keyed by two origins. What does it mean to include or exclude an origin in the API? Would we need new options?
- [oliver] Storage partitioning hasn't shipped in Chrome, but will ship at some point.
- [sam] For our use case, we often want to clear everything except specific sites where you're logged in.
- [tomislav] Please add a comment to the issue to describe this use case.
- [sam] How about the cookieStoreId property?
- [rob] cookieStoreId is meant to be relatively scoped and doesn't scale well to one for every website. In the Cookies API I introduced a “partitionKey” concept to cover storage partitioning.
- https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies#storage_partitioning
- I have discussed this before in discussions in the Privacy CG, at privacycg/CHIPS#6
- [simeon] Going back to the question of whether this should clear only the top level origin or if it should cascade into partitions, my gut feeling is that we should default to cascading as that more closely matches my expectations as a developer. That said, partitionKey sounds like a useful capability. May be better to expose this as a control than take an opinionated stance in the API.
- [sam] How do browsers feel about origins vs. hostnames?
- [rob] Please compare origins and hostnames and show the current and desired behavior in Firefox/Chrome. I expect origins to be a more useful primitive in the long term, but that needs to be verified.
Issue 386: Invoke activeTab from panel.onShown user interaction
- [timothy] Basically, the request is to trigger activeTab when the user interacts with the devtools panel. This capability makes sense to me.
- [simeon] Hadn't previously considered this, but it seems like an appropriate trigger and I can see how it would be materially useful.
- [oliver] Granting activeTab when the devtools is shown sounds good, not sure if panel.onShown is the right signal.
- [tomislav] The devtools.inspectedWindow.eval API already offers the requested capabilities.
- [timothy] Often this kind of extensions already do both.
- [tomislav] Supportive of this.
- [timothy] Supportive of this; Safari's devtools.inspectedWindow.eval currently requires extra permissions (prompts through UI if needed). Reducing the barrier by granting activeTab when the panel is shown would streamline this.
- [oliver] I'll add follow-up:chrome.
- [simeon] I don't know if just opening the devtools is a good enough signal. That only signals that the developer wants to use A developer tool, not a specific extension.
- [rob] The devtools.inspectedWindow.eval method offers similar capabilities.
- [simeon] Host permissions offer more functionality through extension APIs, more compared to just eval. E.g. with host permissions webRequest/DNR can see all requests, the cookies API can see more cookies (e.g. http-only), etc.
- [timothy] Need more thoughts, but I am still broadly supportive of this.
- [rob] Perhaps we need to define the expectations of activeTab. For example, a current feature gap I see is that an extension cannot get access to iframes with just activeTab. That makes sense from the security perspective, but it is a feature gap nevertheless.
Issue 387: Inconsistency: Permissions Inconsistency with New "SidePanel"
- [oliver] In the design doc, we explained this intentional divergence.
- [rob] That information is public, I quoted the relevant part of the doc in the issue: #387 (comment)
- [simeon] The goal of this group is to align on a common API. The intentional introduction of a different API surface is frustrating and counter-intuitive to extension developers. Eventual consistency would be nice.
- [tomislav] Usually how we handle things like this, when there is a meaningful difference; if possible we try to implement something compatible and add extra features on top of it. E.g. We re-used cookieStoreId and expanded it.
- [tomislav] Since several browsers implemented this for years before Chrome, it would have been nice to build on top of the sidebar_action API.
- [rob] Another recent example is the search API. Firefox had the search API before, Chrome implemented it later with a different method. For cross-browser compatibility Firefox ultimately decided to implement both methods.
- [rob] Would Google be receptive to implementing sidebar_action for compatibility, potentially built on top of the sidepanel primitive?
- [oliver] We haven't discussed that yet. I'll follow-up with the Chrome team.
- [jackie] Similar to tab groups feature, different browsers may have different designs.
- [timothy] We're looking into whether the tabGroups API can be massaged to work for Safari's version of the “tab groups” feature.
Issue 388: Web storage in extensions: quota, eviction and unlimitedStorage
- [jackie] web storages in extension should not be evicted by default.
- [timothy] We have problems with extensions using DOM storage (localStorage, IndexedDB, etc.). In Safari, the host name changes at every relaunch, so we have to migrate data all the time. I would prefer if extensions use the storage extension API.
- [rob] These APIs have different use cases, and IndexedDB can save more types than the storage API.
- [simeon] The DOM storage APIs has a larger engineering team behind it than the extension storage API.
- [simeon] The core of this issue is the question of how an extension can store data and not lose it?
- [timothy] Safari doesn't delete the data until about 1 hour after uninstallation.
- [timothy] The discussion aside, it's not clear what the ask here is.
- [rob] The ask here is to guarantee extension data to not be evicted. Given your previous context I suppose that you probably want to discuss this internally before deciding on a resolution.
- [timothy] I'll add the follow-up label for Safari.
- [oliver] Chrome seems to already support this, but I'll double check before adding labels.
Oliver: runtime.getContexts()
- [oliver] runtime.getContext() is now available for testing in Chrome without flags
- [rob] The design doc was merged at #358.
The next meeting will be on Thursday, May 25th, 8 AM PDT (3 PM UTC).