Agenda discussion for public meeting on 2024-05-09

[Rob--W]

This issue is used to collect topic suggestions for our May 9, 2024 meeting. We will stop accepting suggestions ~48 hours before the meeting and the final agenda will be added to the meeting notes doc ~24 hours before the meeting.

The content below this line will be copy-pasted to the agenda section of the meeting.

Agenda

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 blåcklist+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.

[xeenon]

I will be on vacation for this meeting. @dotproto is the regularly scheduled chair anyway.

[hanguokai]

I will discuss #258 . Because @rdcronin recently replied to the issue, and I wrote a very detailed explanation to him. I hope Chrome representatives carefully consider it before the meeting. If you are busy recently, we can also discuss it at another time.

[oliverdunk]

I'd like to nominate https://github.com/w3c/webextensions/issues/160 for the timely issues section. On the Chrome side, it is becoming more likely we might be able to ship browser.action.openPopup() in the coming months and so I want to resolve some outstanding questions.

There are two things I'd like to discuss:

• Supporting windowId for non-active windows. I think the general assumption from Chrome's initial proposal was that this would be allowed and the window would be focused so the popup could be shown. However, there is concern that for us it would be hard to properly wait for the window to be focused before opening the popup. Given there are workarounds (calling chrome.windows.update) and this is likely an edge case, we are leaning towards throwing an error in this case, at least to begin with. That would allow us to ship sooner.
• What should happen if another extension has a popup open when the API is called? When I last tested, Safari supported this and closed the other popup. Firefox (when run with the right flags to remove the user gesture requirement) allows this but currently leaves the other popup open. We don't have strong opinions and are happy with the consensus, as long as we acknowledge the risk of one extension closing another extension's popup which may cause a user to lose state.

Beyond these two questions it seems like the implementations across browsers broadly align and we should be good.

[tophf]

What should happen if another extension has a popup open when the API is called

The new extension's icon gets some visual indication/decoration and is revealed in the toolbar in case it wasn't pinned (if there's enough space, otherwise the extensions menu gets this decoration and the extension is listed at its beginning). The promise is resolved with something that indicates this state e.g. 'pending' or {pendingActivation: true}. It can be canceled by calling chrome.action.openPopup({cancel: true, windowId: 123}) or via a new method.

[oliverdunk]

It would also be great to discuss https://github.com/w3c/webextensions/pull/585 and confirm we are happy to merge.

[carlosjeurissen]

We can also quickly cover https://github.com/w3c/webextensions/issues/296 to conclude progressive removal of subtags is the way forward for now.

[Rob--W]

Closing this one, the meeting has concluded and the next agenda topic is at #609.

We can also quickly cover #296 to conclude progressive removal of subtags is the way forward for now.

This topic did not make it to today's agenda.