Describe the bug
This issue was only observed on a Mac.
This issue is possible to trigger on Chrome, but on Safari it's easy to trigger after multiple aborts of a passkey-verify, since the rate limit is increasing the time for the authenticator to open.
If a user on safari uses our UI components and in the login flow manages to click on the "Use email verification" or "Use phone verification" **before the authenticator opens, the browser completely freezes and the user cannot do anything except force to quitting the browser.
To Reproduce
On MacOs with lots of passkeys on it (Network throttling might help)
Use a desktop browser to go to a playground application or to our developer panel.
Go to login and enter your identifier.
Get ready to quickly click on a fallback option in the passkey-verify screen.
Click continue and immediately click on the a fallback button, before the authenticator opens.
User is taken to the EmailOTP screen but the browser is completely freezed.
Expected behavior
User is directed to EmailOTP screen and can continue with OTP screen.
Additional context
Assumption is that the Authenticator is not killed correctly and the browser still behaves as the authenticator is open, even if it's not shown to the user.
Describe the bug This issue was only observed on a Mac.
This issue is possible to trigger on Chrome, but on Safari it's easy to trigger after multiple aborts of a passkey-verify, since the rate limit is increasing the time for the authenticator to open.
If a user on safari uses our UI components and in the login flow manages to click on the "Use email verification" or "Use phone verification" **before the authenticator opens, the browser completely freezes and the user cannot do anything except force to quitting the browser.
To Reproduce
On MacOs with lots of passkeys on it (Network throttling might help)
Expected behavior User is directed to EmailOTP screen and can continue with OTP screen.
Additional context