Open Bug 2001891 Opened 23 days ago Updated 5 days ago

Logging into google account locks the entire browser

Categories

(Core :: DOM: Web Authentication, defect)

Product:
Core
Component:
DOM: Web Authentication
Version:
Firefox 145
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: andrewjarick, Unassigned, NeedInfo)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0

Steps to reproduce:

Any time i try to login to my google account, and the google login page displays (including the links "using a passkey" and "try another way") the entire browser locks up. This issue occurs on multiple Mac computers. MacOS 15.6.1

Actual results:

The entire browser locks up as soon as the google sign in screen is displayed and becomes unresponsive. Activity manager doesn't show it as not responding. Right-click Quit does nothing. The browser must be force quit.

Expected results:

It should have displayed the passkey, and allowed login to google.

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.

Component: Untriaged → DOM: Web Authentication
Product: Firefox → Core

Adding more context: The browser is freezing when it is trying to display the apple passkey dialog (using FaceID or Finger Print). Since a passkey was previously setup, there is NO WAY around this without using another computer to disable passkey.

Is the passkey dialog ever visible? This sounds like it might be a bug in macOS. Do you have an update available?

For technical reasons, the system dialog needs to be opened from Firefox's main thread, which means that a macOS bug that causes the system dialog to crash or hang prior to the dialog being shown can cause Firefox to crash or hang as well.

(In reply to John Schanck [:jschanck] from comment #3)

Is the passkey dialog ever visible? This sounds like it might be a bug in macOS. Do you have an update available?

For technical reasons, the system dialog needs to be opened from Firefox's main thread, which means that a macOS bug that causes the system dialog to crash or hang prior to the dialog being shown can cause Firefox to crash or hang as well.

Hi, thanks for the reply. Here are the clarifications:

  1. The passkey dialog is never displayed at any point.
    The moment Firefox initiates a WebAuthn request (e.g., Google SSO), the entire Firefox UI freezes.
    The system passkey window does not appear on-screen, in Stage Manager, Mission Control, or hidden behind windows.

  2. This issue only happens in Firefox, not in any other browser.
    I have tested the exact same Google SSO flow on:
    • Safari
    • Chrome
    • Edge
    All of them display the macOS passkey prompt correctly and complete the authentication successfully on macOS 15.6.1 (Sequoia).

  3. Because other browsers work, this strongly suggests Firefox is not handing off the passkey request correctly to the new Sequoia authentication API.
    Since the problem is isolated to Firefox, it does not appear to be a system-wide passkey dialog failure.

  4. The failure mode matches a WebAuthn deadlock on macOS 15 specifically.
    Under Sequoia, Apple changed the LocalAuthentication / Passkey subsystem.
    It appears Firefox is calling the old handoff method from the main thread that is no longer accepted by the updated API, causing Firefox to lock up, waiting for a modal that never launches.

  5. This is reproducible on two separate Macs:
    • MacBook Pro (M1)
    • MacBook Air (M3)
    Both running macOS 15.6.1.
    The browser profile was fully reset, and Firefox was reinstalled cleanly.

  6. Repro steps (100% consistency):
    • Open Firefox
    • Go to any Google service
    • Trigger Google SSO (account chooser → continue)

  • Firefox locks instantly before the system dialog appears
  • Only force-quit can close the browser

(In reply to John Schanck [:jschanck] from comment #3)

Is the passkey dialog ever visible? This sounds like it might be a bug in macOS. Do you have an update available?

For technical reasons, the system dialog needs to be opened from Firefox's main thread, which means that a macOS bug that causes the system dialog to crash or hang prior to the dialog being shown can cause Firefox to crash or hang as well.

Hi, thanks for the reply. Here are the clarifications:

  1. The passkey dialog is never displayed at any point.
    The moment Firefox initiates a WebAuthn request (e.g., Google SSO), the entire Firefox UI freezes.
    The system passkey window does not appear on-screen, in Stage Manager, Mission Control, or hidden behind windows.

  2. This issue only happens in Firefox, not in any other browser.
    I have tested the exact same Google SSO flow on:
    • Safari
    • Chrome
    • Edge
    All of them display the macOS passkey prompt correctly and complete the authentication successfully on macOS 15.6.1 (Sequoia).

  3. Because other browsers work, this strongly suggests Firefox is not handing off the passkey request correctly to the new Sequoia authentication API.
    Since the problem is isolated to Firefox, it does not appear to be a system-wide passkey dialog failure.

  4. The failure mode matches a WebAuthn deadlock on macOS 15 specifically.
    Under Sequoia, Apple changed the LocalAuthentication / Passkey subsystem.
    It appears Firefox is calling the old handoff method from the main thread that is no longer accepted by the updated API, causing Firefox to lock up, waiting for a modal that never launches.

  5. This is reproducible on two separate Macs:
    • MacBook Pro (M1)
    • MacBook Air (M3)
    Both running macOS 15.6.1.
    The browser profile was fully reset, and Firefox was reinstalled cleanly.

  6. Repro steps (100% consistency):
    • Open Firefox
    • Go to any Google service
    • Trigger Google SSO (account chooser → continue)

  • Firefox locks instantly before the system dialog appears
  • Only force-quit can close the browser

I'm not able to reproduce this on an M4 with macOS 15.7.1.

Do you have any extensions installed that use passkeys, e.g. LastPass, 1Password, or Bitwarden? Does this happen in a new profile?

Also, did this start happening when you upgraded to 145? Do you know what version you were on previously? If you're willing to narrow it down using mozregression that would help us a lot.

Heitor, this kind of looks like Bug 1865128. Has anything changed in how we request the passkey entitlement?

Flags: needinfo?(hneiva)

Not that I'm aware of.

Maybe @Haik would know?

Flags: needinfo?(hneiva) → needinfo?(haftandilian)

No, we haven't changed the entitlement configuration. I just checked to confirm the entitlement is still present on the Release channel Firefox.

@Andrew, thanks for the report and detailed debugging. If Firefox is hung, it is usually possible to collect a Firefox performance profile using these steps https://profiler.firefox.com/docs/#/./async-posix-signal-control from the command line. If you're comfortable using the command line, it would be worth a try to follow the steps once Firefox is in the hung state. That will generate a performance profile that can be viewed in the Firefox profiler (https://profiler.firefox.com/) and shared with us. It might show us where Firefox is blocked.

The Activity Monitor app can also be used to collect a "sample" of Firefox's activity when it is hung. It provides less detail though.

Flags: needinfo?(haftandilian) → needinfo?(andrewjarick)

(In reply to John Schanck [:jschanck] from comment #6)

I'm not able to reproduce this on an M4 with macOS 15.7.1.

Do you have any extensions installed that use passkeys, e.g. LastPass, 1Password, or Bitwarden? Does this happen in a new profile?

Also, did this start happening when you upgraded to 145? Do you know what version you were on previously? If you're willing to narrow it down using mozregression that would help us a lot.

Yes, I have LastPass installed. And Authenticator.

Yes, that's right, I noticed this issue after upgrading Firefox.

Flags: needinfo?(andrewjarick)

(In reply to Haik Aftandilian [:haik] from comment #9)

No, we haven't changed the entitlement configuration. I just checked to confirm the entitlement is still present on the Release channel Firefox.

@Andrew, thanks for the report and detailed debugging. If Firefox is hung, it is usually possible to collect a Firefox performance profile using these steps https://profiler.firefox.com/docs/#/./async-posix-signal-control from the command line. If you're comfortable using the command line, it would be worth a try to follow the steps once Firefox is in the hung state. That will generate a performance profile that can be viewed in the Firefox profiler (https://profiler.firefox.com/) and shared with us. It might show us where Firefox is blocked.

The Activity Monitor app can also be used to collect a "sample" of Firefox's activity when it is hung. It provides less detail though.

I followed the async-posix-signal-control instructions exactly:

  • Launched Firefox from Terminal
  • Reproduced the hang.
  • Found the correct Firefox PID.
  • Sent the profiler trigger signal
    However, Firefox never generated a performance profile, no perf-profiles directory was created in either of my profile folders, and Firefox remained completely frozen without opening the profiler tab. I repeated the test several times with the same result.

Since the profiler couldn’t capture anything, I generated a macOS Activity Monitor Sample Process while Firefox was frozen. I can't upload the text, so i pasted it in pastebin https://pastebin.com/MsD94FVe

The severity field is not set for this bug.
:jschanck, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jschanck)
You need to log in before you can comment on or make changes to this bug.