macOS passkey modal disappears and blocks Firefox main thread if the user has a Touch ID fingerprint registered
Categories
(Core :: DOM: Web Authentication, defect, P2)
Tracking
()
People
(Reporter: tetsuharu, Assigned: keeler)
References
Details
Attachments
(3 files)
Environments
- macOS Ventura 13.6.1(22G313)
- Intel x64
- Firefox Nightly: https://hg.mozilla.org/mozilla-central/rev/30972f1e5f790da2db4cf542e49e522275787122
- Set security.webauthn.enable_macos_passkeys=true
Steps to Reproduce
- Open https://github.com/login
- Fill my id & password and click "Sign in" button.
- Click "Use passkey or security keys" button.
Actual Results
- Display macOS's passkey window but it will be closed soon automatically.
- Cannot interact with Firefox window that contains the tab opening the above page.
- It looks like Firefox freezes.
- But I still interact with the window from menu (e.g. "File" -> "New Window").
Expected
- Firefox window should works well.
- Success to sign in with macOS' passkey window.
Note
- I confirms this is reproducible on macOS Sonoma 14.1.1 on Apple Silicon.
| Reporter | ||
Updated•2 years ago
|
I can confirm that this happened to me as well a few days ago, for some reason not all devices are affected since I tried on multiple MacBooks both MacOS 13.6 (22G120) and MacOS 14 (all intel). On the single device that was affected I created a new user and the dialogue was not closed anymore automatically.
I also tried to get some logs by setting macoswebauthnservice:5 in about:logging or setting it as environment variable but I got an empty file.
Attaching a video with the issue using https://webauthn.io/ website.
Comment 2•2 years ago
|
||
I've reproduced this and I found that it depends on whether the user has a Touch ID fingerprint registered. If there's a fingerprint, the dialog disappears. If not, it shows.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
Having the * denominator causes a bug with passkeys
Comment 4•2 years ago
|
||
Echoing something in the phab revision for posterity:
To add an explanation for the record: we don't need this for the developer entitlements because they don't use the passkey entitlement (and the requisite application-identifier entitlement) because that requires signing with an official Developer ID cert which we do not do for try builds.
Comment 6•2 years ago
|
||
| bugherder | ||
Comment 7•2 years ago
|
||
The patch landed in nightly and beta is affected.
:keeler, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox121towontfix.
For more information, please visit BugBot documentation.
Just as a note, QA will require this to be uplifted in Firefox 121 beta build so we can complete the testing on this feature since we do have tests that also cover the Touch ID being activated.
Comment 9•2 years ago
|
||
Having the * denominator causes a bug with passkeys
Original Revision: https://phabricator.services.mozilla.com/D193977
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Uplift Approval Request
- Is Android affected?: no
- Steps to reproduce for manual QE testing: Register a credential on webauthn.io with security.webauthn.enable_macos_passkeys set to true.
- Risk associated with taking this patch: No foreseeable risk
- String changes made/needed: None
- User impact if declined: passkeys won't work until next beta release
- Fix verified in Nightly: yes
- Code covered by automated testing: no
- Explanation of risk level: working on nightly
- Needs manual QE test: yes
Comment 11•2 years ago
•
|
||
Comment on attachment 9365039 [details]
Bug 1865128 - Use full bundle id in entitlements
Approved for 121.0b3
Updated•2 years ago
|
Comment 12•2 years ago
|
||
| uplift | ||
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Verified as fixed on Mac 13/Mac 14 using FF builds 121.0b3 and 122.0a1.
Mark as verified.
| Assignee | ||
Updated•2 years ago
|
Description
•