Ensure consistency of `action.openPopup` API across browsers

[oliverdunk]

A Chromium bug was recently opened sharing an action.openPopup API, and a basic implementation has shipped restricted to the dev channel. This is super exciting since it's the first time Chrome extensions look set to get this ability.

Since Firefox has already implemented browserAction.openPopup, I'm curious on a few things:

• Would Mozilla be willing to either support the new namespace as an alias or try to work with Google to encourage use of the existing API naming? In an ideal world I would rather see Chromium implement the Firefox API, since that has already shipped and seems to work well. However, they seem to be wanting to diverge from the private API they have already implemented so I'm not sure how feasible that is.
• One big step the Chromium API has taken is removing the requirement for a user action. The API overview doc says that they "do not currently plan any mitigations for attacks of annoyance" because "extensions can already do far worse than this with the tabs API and window creation." Would Mozilla consider the same? It immediately solves some of the native messaging use cases raised at the start of Discuss and encourage adoption of browserAction.openPopup() #15.

---

ℹ️ Update: The initial questions here have been resolved and this issue is now tracking more nuanced behaviour differences between browsers. See the current behaviours and proposed standard behaviours.

[oliverdunk]

@zombie / @Rob--W, it would be great to get your input from the Mozilla side.

@dotproto, I'm not sure if there's anything you can share on behalf of Google? Would you be open to discussions about using the same API namespace as Mozilla or is that off the cards given that you already use that namespace for an internal API? The crbug seems quiet unfortunately.

[zombie]

• Would Mozilla be willing to either support the new namespace as an alias or try to work with Google to encourage use of the existing API naming?

We already added support for the action manifest key/namespace for MV3 in bug Bug 1706398.

• One big step the Chromium API has taken is removing the requirement for a user action. The API overview doc says that they "do not currently plan any mitigations for attacks of annoyance" because "extensions can already do far worse than this with the tabs API and window creation." Would Mozilla consider the same?

This seems reasonable, I filed Bug 1755763 to consider it.

Another difference is that Chromium has an optional windowId param (though the proposal doc mentions tabId instead?), which seems useful.

[xeenon]

We (Apple) would implement the windowId version to match Chrome. We could add tabId support too if others agree.

[dotproto]

I want to track down why we the design doc mentions tabId with windowId as a potential future enhancement, but we only implemented windowId. Unfortunately I haven't been able to find the time yet.

Links for later follow-up: crbug.com/1245093

[oliverdunk]

I've been working on a Firefox patch to bring the behaviour closer to the Chromium implementation. Given this has shipped in Safari Technology Preview too, I wanted to investigate the behaviour in other browsers to make sure it was consistent.

Sharing the results here for longevity...

Behaviour	Chrome	Safari 16+
Calls onClicked handler with popup	No	No
Calls onClicked handler without popup	No	No, focuses window
Default window	Active tab in topmost window	Active tab in topmost window
Can call for private window	Unable to test¹	Yes
Closes popup when open	Throws error (no active browser window)	No, focuses window
Closes popups from other extensions	Throws error (no active browser window)	Yes
Requires user gesture	No	No
Grants activeTab permission	No	Skips permission prompt, API calls hang. Reloading the popup window restores ability to make API calls and request permissions.
User gesture grants activeTab	No	NA - content script injection is tied to granting host permissions
Callable from content script	No	No
Behaviour after .disable() call	Throws error (no popup for tab)	Ignored, popup continues to open
Behaviour when hidden in browser-specific UI	Icon is revealed, popup opens	Window focused, popup does not open
windowId for minimized window	Unable to test¹	Window is maximised
windowId for hidden window	Unable to test¹	Popup opens, window only focused if Safari is active app

¹ Notably windowId doesn't seem to be working in Chrome Canary (other than for already focused windows), which I'm fairly confident is a regression from when I last tested. There's already a comment about that and I've left another one.

[Rob--W]

Thanks for documenting the observed behavior @oliverdunk !

Here are some more interesting scenario's that aren't in the table yet:

• When a user gesture is present, is the activeTab permission granted and effective when action.openPopup is called?
• When the popup is disabled via a .disable() call in the API, what does openPopup do?
• When the extension button is hidden via browser-specific UI, what does openPopup do?
• When the window is in the background, what happens when openPopup is called with a windowId?
• When the window is minimized, what happens when openPopup is called with a windowId?

[oliverdunk]

@Rob--W: I went ahead and updated the table with those! Definitely some interesting results.

[oliverdunk]

Here is my proposed standard based on the behaviour which feels best in each case:

Behaviour	Proposed Standard
Calls onClicked handler with popup	No
Calls onClicked handler without popup	No
Default window	Active tab in topmost window
Can call for private window	Yes, but only if extension enabled in private contexts
Closes popup when open	No, ignores request and potentially throws error
Closes popups from other extensions	No, ignores request and potentially throws error
Requires user gesture	No
Grants activeTab permission	No
Behaviour when clicking browser icon would normally show permission prompt	Permission prompt shows, or browser indicates to user popup is trying to open. Granting permission opens popup.
User gesture grants activeTab	Optional. Preserved in Firefox for backwards compatibility.
Callable from content script	No
Behaviour after .disable() call	Ignored, potentially throws helpful error
Behaviour when hidden in browser-specific UI	Icon is revealed, popup opens
windowId for minimized window	Windows maximized, popup shows. Ignored if browser is not focused app.
windowId for hidden window	Window focused, popup shows. Ignored if browser is not focused app.

I've added "Behaviour when clicking browser icon would normally show permission prompt" for the following UI in Safari:

The current Safari behaviour is to open the popup skipping this prompt (and not granting permissions), but I'm actually not sure if this is the way to go. Open to feedback there.