Passkeys fallback: wait the window.onfocus event

[a2kolbasov]

Some browsers (like Firefox) reject requests to navigator.credentials.create/get if the page is out of focus (meaning the built-in functionality -- the originalCredentials variable). When the user selects a passkey in KeePassXC-desktop, there is no focus on the page. When the request is canceled, a race begins between whether the focus returns to the page and whether the originalCredentials call occurs. It depends on the operating system's window manager.

If the user starts switching windows during the request, and when canceling the request, focus is returned to a non-browser, the browser will reject the request regardless of the OS.

Resolves #2493

Screenshots or videos

Testing strategy

As in #2493 (comment).

It is also possible at the time of the Passkey request:

1. Do not cancel it
2. Return to the browser and focus on the Web Console (click on the code entry field), docking option is not "Separate Window")
3. Return to KeePassXC and cancel the request

The focus will return in DevTools and the browser will reject the request.

If you need to call the built-in library in Firefox to work with USB keys, regardless of the OS: go to about:config, set security.webauth.webauthn_enable_softtoken to true.

Type of change

• ✅ Bug fix (non-breaking change that fixes an issue)

[varjolintu]

This is clearly some bug in Firefox itself.

[droidmonkey]

This is an ugly workaround to what is ultimately browser behavior. The behavior should be reported to mozilla for correction.

[a2kolbasov]

Chrome behaves differently, but still in a similar way.

Disable keepassxc-browser, go to https://github.com/login, execute

setTimeout(() => document.querySelector('.js-webauthn-confirm-button').click(), 5_000)

, switch to another tab and wait for the timer to expire. When you return, you will see the same error in the console.

---

Browsers block requests from inactive pages, but they define its activity differently.

The call from the password manager is no different (for browsers) from the code on the page that calls navigator.credentials.get.

And the spoof of navigator.credentials itself is generally ugly too. But this is a hack due to the fact that browsers do not provide an API similar to the API for HTTP Auth (or the like).

---

And here are examples from the WebAuthn specification:

• § 5. Web Authentication API
• § 5.1.3. Create a New Credential, № 2.2 - 2.3
• User Consent

[a2kolbasov]

The same thing happens in Safari. The video shows:

1. If the focus is on DevTools
2. If the focus is on window.top instead of window.self.

safari.mp4

tested on a self-written site via BrowserStack, MacOS Tahoe, Safari 26.2

---

I conducted additional testing. document.hasFocus() returns true in all iframes, regardless of which one is being checked (document.hasFocus() === window.top.document.hasFocus() always). However, the focus event does not pass through an iframe. When switching between applications, the focus returns to the last active iframe (where the WebAuthn call was made), and the event should be handled on that iframe.

I also replaced a callback with await Promse<void>.