2026687 - Web extension popups close when using navigator.credentials.create

Status: NEW

(WebExtensions :: Frontend, enhancement)

Description

[Tyler]

Attachment: A demonstration of the issue on extension popup

Comment 1

[Tyler]

A change has recently been added to better support WebAuthn in Firefox web extensions: https://bugzilla.mozilla.org/show_bug.cgi?id=1956484. That effort is greatly appreciated.

However, while this experience works well on web extension pages, such as a dedicated tab, web extension popups (where extension developers primarily provide their authentication experiences) auto-close when displaying the modal dialog on navigator.credentials.create and navigator.credential.get, not giving the user a chance to create or use a passkey.

This is a request to better support WebAuthn in the web extension browser action popup. I've re-attached the sample extension that was used to file the original request to allow web extensions to claim relying party identifiers for domains they have host permissions for.

Comment 2

[Tyler]

Attachment: Sample web extension to demonstrate the issue

Comment 3

[Tyler]

Attachment: Demonstration of WebAuthn working as expected on extension page

Comment 4

[Tyler]

This fix would also bring Firefox in line with Chromium and Safari-- both support a WebAuthn ceremony triggered from a web extension popup without closing.

Comment 5

[Rew Islam]

+1 on this from Dashlane.

Comment 6

[Rob Wu [:robwu]]

Moving bug to WebExtensions; although the entry point is the WebAuthn API, the feature request (=requesting the popup to stay open) is about the extension popup panel.

The webauthn prompt is not the only kind of prompt that causes the extension popup to close; there are other reports, e.g. color picker causing the extension popup to be closed (bug 1884731).

Comment 7

[Rob Wu [:robwu]]

A potential way to fulfill the feature request is to introduce a mechanism for extensions to opt out of closing the popup, whether automatically or through an API. I'll discuss that with my team.

When the popup does not auto close, we should make this obvious to the user, along with a way to close anyway, e.g. by rendering a new bar at the top of the extension popup with a X button.

Comment 8

[Rob Wu [:robwu]]

Is it a reasonable work-around to pop out to an extension window when you want to query credentials?

No promises, but would the ability to call this API from an extension background page be a feasible work-around? We currently reject calls with CredentialsContainer request is not allowed. when the API call is made from non-active tabs.

Comment 9

[Rew Islam]

(In reply to Rob Wu [:robwu] from comment #8)

Is it a reasonable work-around to pop out to an extension window when you want to query credentials?

This was suggested for the original issue:

https://github.com/w3c/webextensions/issues/238#issuecomment-1613021073

Comment 10

[Tyler]

(In reply to Rob Wu [:robwu] from comment #8)

Is it a reasonable work-around to pop out to an extension window when you want to query credentials?

No promises, but would the ability to call this API from an extension background page be a feasible work-around? We currently reject calls with CredentialsContainer request is not allowed. when the API call is made from non-active tabs.

To echo rew.islam, I'm aware of the workaround to pop out an extension tab or window to call WebAuthn API's, and we even already offer that in some cases. But users prefer the more streamlined self-contained experience in the extension popup.

Calling from the extension background page sounds viable. I do wonder, would that still close the extension popup? If so, we'd still want a way to continue the user flow in browser_action without requiring a click to open it.

I see that Firefox now supports calling the browser.browserAction.openPopup() API as long as that window is focused (and that the user gesture requirement has been dropped, although maybe authorizing a passkey would have qualified as a user gesture anyways). If the browser window was still considered active/focused after interacting with the modal dialog, then I think that could work (at least in my view).

Comment 11

[Rob Wu [:robwu]]

(In reply to Tyler from comment #10)

(In reply to Rob Wu [:robwu] from comment #8)

No promises, but would the ability to call this API from an extension background page be a feasible work-around? We currently reject calls with CredentialsContainer request is not allowed. when the API call is made from non-active tabs.

Calling from the extension background page sounds viable. I do wonder, would that still close the extension popup?

Yes.

If so, we'd still want a way to continue the user flow in browser_action without requiring a click to open it.

I see that Firefox now supports calling the browser.browserAction.openPopup() API

I was thinking of action.openPopup() indeed.

as long as that window is focused (and that the user gesture requirement has been dropped, although maybe authorizing a passkey would have qualified as a user gesture anyways).

That would not have counted as a user gesture.

If the browser window was still considered active/focused after interacting with the modal dialog, then I think that could work (at least in my view).

Many ifs here. To that list of conditions I can add another: if the background script is still running (event page can shut it down).

I think that between the options, automatically keeping the popup open while a credential request is pending, or an API to explicitly keep the popup open (which I described in comment 7) would be the most reliable approaches.

P.S. I still have not met with my team to discuss this yet.

Comment 12

[Tyler]

Attachment: Test creating a credential in the demo extension with Disable Popup Auto-Hide enabled in the dev tools

Comment 13

[Tyler]

I just simulated automatically keeping the popup open during the credential request by using the Disable Popup Auto-Hide setting in the dev tools, and it works pretty well (I attached a video demonstration).

Comment 14

[Rob Wu [:robwu]]

Discussed with :mixedpuppy and :zombie - we are in favor of addressing this issue if feasible.

Question is whether we can reliably detect the start of the passkey flow and the full completion, AND tie that to the "keep extension popup" open. At the same time, we should try to avoid keeping the popup open for longer than needed.