2024-05-09-wecg.md

WECG Meetings 2024, Public Notes, May 9

• Chair: Simeon Vincent
• Scribes: Rob Wu

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

Agenda: discussion in #603, 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 (30 minutes)
  • Issue 600: Request immediate injection of manifest script registered with document_idle
  • Issue 601: Proposal: StorageArea.getAllKeys()
  • Issue 604: [DNR] extensionPath should not require exposing the target in web_accessible_resources
  • Issue 605: Inconsistency: inIncognitoContext is not available in a userscript world in Chrome
  • Issue 606: userScripts API: re-order without re-registering everything
  • Issue 607: userScripts API: injection blocklist+allowlist just for this API
• Timely issues (10 minutes)
  • Issue 160: Ensure consistency of action.openPopup API across browsers
    • (@oliverdunk) (1) supporting windowId for non-active windows, (2) what should happen if another extension has a popup open when the API is called?
• Check-in on existing issues (10 minutes)
  • Issue 258: Per-extension language preferences
    • (@hanguokai) Follow up on recent discussion in the comments, discuss next steps.
  • Issue 585: dark-mode: Add a proposal for dark mode extension icons

Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Simeon Vincent (Mozilla)
3. Oliver Dunk (Google)
4. Jackie Han (no affiliation)
5. Steven McLintock (1Password)
6. David Johnson (Apple)
7. Kiara Rose (Apple)
8. Giorgio Maone (NoScript, Tor)
9. Carlos Jeurissen (Jeurissen Apps)
10. Anton Bershanskyi (independent)
11. Richard Worth (Capital One)
12. Tomislav Jovanovic (Mozilla)
13. Solomon Kinard (Google)

Meeting notes

Issue 600: Request immediate injection of manifest script registered with document_idle

• [simeon] Request to offer a way for extensions to request immediate execution of already scheduled content scripts, instead of waiting until document_idle. Rob already commented on the issue and asked whether the extension can use document_end. I also responded and suggested a way to specify an ID and inject scripts via scripting.executeScript.
• [rob] The ID-based approach seems like it may be a good approach. Hesitant about using executeScript() as the injection mechanism, since this use case doesn't always result in code execution like the method normally does.
• [rob] Supportive of the capability to inject once, and pair that with the ability to execute immediately.
• [oliver] Sounds sensible, I'll check with the team.
• [tomislav] Not convinced of the need for a new API, extensions can already specify an earlier runAt.
• [rob] I mentioned document_end before this reason, and that's why I suggested the capability to inject once, which could be combined with a way to inject immediately.
• [tomislav] Not opposed.

Issue 601: Proposal: StorageArea.getAllKeys()

• [simeon] Forked from issue 505, request to retrieve all keys.
• [rob] Firefox and Safari are supportive.
• [oliver] Chrome is also supportive.
• [simeon] Next step is for a proposal to create and a browser to sponsor?
• [rob] Do we need to go through the full proposal process when the proposed extension API is trivial? The method and semantics are unambiguous.
• [simeon] Once there is consensus, an actual proposal signals readiness and commitment to implement an API.

Issue 604: [DNR] extensionPath should not require exposing the target in web_accessible_resources

• [rob] In this case they are essentially exposing extension content to webpages. I support the underlying request to expose extension resources to web pages, but not with extensionPath. I previously proposed a way for extensions to replace a request's response body - that seems like a better solution than.
• [oliver] Opposed too.
• [rob] I will mark the issue as opposed and remark that I'm supportive of a way to replace the response body.

Issue 605: Inconsistency: inIncognitoContext is not available in a userscript world in Chrome

• [simeon] From the issue: chrome.extension is not exposed to the userScript world. There is currently no way to expose it to the isolated world due to the lack of a secure messaging channel. Issue notes that Firefox already expose chrome.extension in the userscript world.
• [rob] Firefox does not expose any extension API in a userScripts world. MV3 userScripts has yet to be implemented, the MV2 userScripts API does not have any extension APIs in the world.
• [tomislav] There is another one, not user script world, but…?
• [rob] Firefox's MV2 userScripts also includes a way to specify an “API script”, which runs in a separate sandbox that “manages” user scripts, supposedly to inject user script APIs.
• [rob] During the in-person meeting in San Diego (meeting notes: 2024-03-20-san-diego-meetup.md), we agreed that we intend to add a way to communicate synchronously between different worlds, including user script worlds and content scripts. This can be used to implement the requested feature.
• [oliver] Reporter called out that even if we had a secure messaging channel, they didn't feel that was sufficient.
• [simeon] How does the existing ecosystem of userscripts access the incognito boolean?
• [rob] They can access the information from the content script.
• [rob] I'm inclined to oppose this feature request, because a generic solution exists that can be used to solve the issue. The issue cited a concern with performance, but in reality I expect user script managers to need a higher-privileged (content script) world to provide an implementation of APIs such as GM_getValue.
• [kiara] We don't support the userScripts API, but I agree that we wouldn't support extension APIs there.

Issue 606: userScripts API: re-order without re-registering everything

• [simeon] toph requests a way for user script managers to reorder without re-registering.
• [rob] Supportive, also of this capability in the scripting API if there is demand for it.
• [oliver] Supportive of the capability. An API proposal would be useful. I can see a reorder method or some sort of priority system.
• [rob] I was also thinking of something like priority.
• [oliver] Like the declarativeNetRequest API.

Issue 607: userScripts API: injection blocklist+allowlist just for this API

• [rob] This capability is already possible. userScripts.update API allows matchPatterns and excludePatterns. This request may make sense in the context of a large number of patterns and a large number of userScripts.
• [oliver] The semantics of exclude/include is unclear.
• [rob] I think that the intended logic is: if listed in the global exclude, look at the global include to determine whether to ignore the exclude. If not excluded, then continue with the usual matching logic.
• [rob] We could expose a hook in the content script world to allow extensions to decide whether or not to perform the userscript injection.
• [oliver] Performance implications are unclear at the moment.
• [rob] I'm neutral. Not a priority.
• [oliver] Personally leaning towards slightly supportive. I can see the complexity for a large number of scripts.

Issue 160: Ensure consistency of action.openPopup API across browsers

• [oliver] (1) supporting windowId for non-active windows, (2) what should happen if another extension has a popup open when the API is called?
• [oliver] openPopup has been blocked for a long time in Chrome, blocked on security. Currently looking into the API itself to see if there are API design issues that we need to resolve first before exposing.
• [oliver] windowId with non-active windows: when the window is minimized, what should we do? Inclined to ignore non-focused windows when windowId is not active.
• [rob] Has anything changed since the patch you contributed to Firefox?
• [oliver] In Firefox, when it was implemented there is a best-effort attempt to focus the window.
• [rob] Workaround when window is inactive is to focus it using the windows API. Doesn't require any special permissions. Are you suggesting authors should always set window focus?
• [oliver] Number of scenarios where opening the popup in inactive windows is expected to be minimal.
• [rob] Makes sense to focus on core cases for the MVP. You intend to drop the user gesture requirement, correct?
• [oliver] Yes.
• [oliver] Other part - what if another extension already has a popup open? Safari closes the popup at the moment. Firefox would have two popups open.
• [rob] That is not by design.
• [tomislav] An extension closing another extension's popup is also not great.
• [oliver] Ultimately comes down to potentially losing state by closing another extension's popup or an extension that has a good reason to open the popup not being able to.
• [rob] Leaning towards returning an error if the popup cannot be opened, including when there are already other extension popups open.
• [tomislav] I'm opposed to unilaterally closing other popups.
• [oliver] Sounds like rejecting is the preferred solution.
• [kiara] On the Safari side, I tend to agree with rejecting.
• [rob] In Firefox, user interaction is currently required. When the user interacts with browser UI, existing extension action popup panels close. As a result, it's not possible to have two concurrent popups.

Issue 258: Per-extension language preferences

• [jackie] Follow up on recent discussion in the comments, discuss next steps.
• [jackie] Devlin followed up to say Chrome is supportive (comment). I understand that browsers are hesitant to specify UI features.
• [rob] If there's consensus on supporting this, I would be supportive. Want to see API proposals – including descriptions of behaviors – before proceeding. Likely won't sponsor this.
• [oliver] If there is no sponsors we could consider supporting it.
• [kiara] Supportive of an API, I could check whether we'd be interested.
• [simeon] What about CSS? E.g. image assets dependent on language.
• [rob] Sounds like one of the cases that should be specified in the proposal.
• [tomislav] Extension requests the locale change, correct? The extension could proactively take action to update the locale.

Issue 585: dark-mode: Add a proposal for dark mode extension icons

• [solomon] Thanks for all the reviews and feedback. We're converging on getting it merged.
• [rob] Everyone has approved. Is there anything that blocks merging?
• [solomon] Nothing to my knowledge. I've been hesitant to resolve other people's discussions.
• [oliver] Since we've all approved, I suggest merging now.
• [carlos] I commented on the issue of having mixed typing and how that should be handled by browsers, which was added to the spec, seems still up to the browser vendors. Should we specify the behavior more explicitly.
• [solomon] I wrote that I was aligned with what you and Timothy had proposed. We could emit a warning but not block installation.
• [rob] Generally, recoverable issues in the manifest should not block installation. Runtime APIs should throw on invalid values to allow feature detection.
• [rob] I'll merge the pull request after this meeting.

The next meeting will be on Thursday, May 23rd, 8 AM PDT (3 PM UTC)