Unable to use WebAuthn in Firefox 124 on MacOS 13.6.5
Categories
(Core :: DOM: Web Authentication, defect)
Tracking
()
People
(Reporter: will.smart, Unassigned)
Details
Attachments
(1 file)
361.05 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36
Steps to reproduce:
- Attempt to register a new webauthn credential on a web site that uses webauthn, like webauthn.io.
- Note that instead of bringing up the system passkey dialog on MacOS, nothing happens.
Actual results:
No dialogs are shown. Repeated attempts at registering a credential result error messages on the web site, but these may be due to the fact that the WebAuthn call is interrupted.
If the browser console is open the first time you attempt to register, the following message appears:
InvalidStateError: JSWindowActorChild.docShell getter: Cannot access property 'docShell' after actor 'LoginManager' has been destroyed LoginManagerChild.sys.mjs:1713
#onDOMDocFetchSuccess resource://gre/modules/LoginManagerChild.sys.mjs:1713
handleEvent resource://gre/modules/LoginManagerChild.sys.mjs:1602
See attached screenshot.
If the security.webauthn.enable_macos_passkeys preference is set to false, the WebAuthn registration is successful, but can not synced passkeys or MacOS platform passkeys.
I can reproduce this issue on MacOS 13.6.5 (Intel Macbook) and Firefox 123.0 or 124. I haven't attempted to downgrade to 123 or earlier to test.
Expected results:
The expected result is that the MacOS system passkey window is displayed, and a passkey can be created.
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Web Authentication' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
I've been following bug 1884159 and can say that your workaround (set security.webauthn.enable_macos_passkeys to false) addressed that issue for me - I am now prompted for my hardware key. I appreciate you sharing that.
Reporter | ||
Comment 3•1 year ago
|
||
(In reply to Blake Johnson from comment #2)
I've been following bug 1884159 and can say that your workaround (set security.webauthn.enable_macos_passkeys to false) addressed that issue for me - I am now prompted for my hardware key. I appreciate you sharing that.
I did see that issue, but it's not clear to me that it's the same root cause, even though the workaround is the same.
Reporter | ||
Comment 4•1 year ago
|
||
May be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1886543
Reporter | ||
Comment 5•1 year ago
|
||
For completeness, the symptoms are the same whether a new credential is being registered or whether you are attempting to authenticate with a previously registered credential. The system passkey dialogs are never invoked. Passkeys are not usable for registration or authentication.
Apple has confirmed that this is due to an update they shipped. It affects "any version of macOS 13 where Safari 17.4 is installed".
Description
•