Browser Freeze on Passkey Call&CallBack Failure

[lucas-riverbi]

Preliminary Checks

• I have read and understood the important section above.
• I have searched existing issues and avoided creating duplicates.
• I am not filing an enhancement request.
• I have checked that this issue cannot be reproduced on Mozilla Firefox.
• I have checked that this issue can be reproduced once I removed all my Mods and Custom CSS.

What happened?

When a saved passkey (via Firefox/ Zen Password Manager or macOS keychain) is detected on a website, Zen Browser on macOS attempts to autofill/use the passkey for login without providing an option to redirect or use an alternative method. This triggers the passkey API (WebAuthn), which causes all browser tabs and windows to freeze immediately. The only recovery method is to force quit the entire Zen Browser process (via Activity Monitor or Cmd+Option+Esc), close all windows, and restart the browser. Simply closing the affected tab/window or using Cmd+W does not resolve the freeze—it propagates to the entire session.

Workflow shattered especially in multi-tab research sessions (including Zen's custom workspaces or vertical tabs) where navigating to a login prompt (e.g., Google services or other passkey-enabled sites) halts all activity. No error messages appear in the console before the freeze. The issue seems tied to Zen's integration with system passkeys and Firefox's WebAuthn handling.

Environment

• OS: macOS (version: [e.g., Sonoma 14.5 – specify the exact version from Apple Menu > About This Mac])

• Browser: Zen Browser

• Browser Version: [e.g., 1.6b (based on Firefox 128 ESR) – check via about:support or Help menu]

• Hardware: MacBook (model: [e.g., M2 MacBook Pro 2023], RAM: [e.g., 16GB])

• Other: Passkeys managed via Zen's built-in password manager, Firefox Sync, or macOS keychain integration. Issue occurs across multiple websites that support passkeys (e.g., Google login pages, GitHub, or other WebAuthn sites). Tested without Zen's custom extensions/themes (e.g., uBlock Origin if bundled).

Steps to Reproduce

1. Ensure a passkey is saved for a Google account (or similar) in Zen Browser's password manager on macOS (via Settings > Privacy & Security > Logins and Passwords).

2. Open Zen Browser with multiple tabs/windows open (e.g., research tabs in different Zen workspaces or vertical tabs enabled).

3. Navigate to or click into a site that triggers passkey detection (e.g., open a new tab and go to accounts.google.com, or visit a site like github.com that prompts for login).

4. When the browser detects the saved passkey and prompts to use it for login (no secondary options like "Use password instead" or redirect), it automatically calls the passkey API.

5. The entire browser freezes—no tabs respond, no scrolling, no switching windows or workspaces. Cmd+Tab may work, but Zen remains unresponsive.

Actual Results

• All tabs/windows (including Zen's custom UI elements like sidebars) freeze immediately upon passkey API invocation.

• Browser cannot be closed normally (e.g., Cmd+Q or closing windows individually hangs indefinitely).

• Force quit required (Activity Monitor > Quit Zen Browser process).

• Upon restart, all unsaved work/tabs/workspaces are lost.

• Reproducible every time a passkey-enabled login is attempted in a multi-tab session.

Additional Context / What I've Tried

No console errors (via Developer Tools > Console) before freeze. Crash logs available in ~/Library/Application Support/Zen/Crash Reports (or equivalent Firefox path). If it's a conflict with macOS Touch ID/Keychain or Zen's custom privacy features, unclear—happens even with sync paused.

Expected behavior

• Passkey prompt should allow fallback options (e.g., "Use password instead" or redirect to manual login) without freezing the browser. - Freeze should not affect other tabs/windows/workspaces; at worst, only the affected tab hangs, allowing normal closure/restart per window. - Browser should remain responsive during passkey authentication, with clear error handling if it fails (similar to vanilla Firefox behavior).

Actual behavior

When a saved passkey (via Firefox/ Zen Password Manager or macOS keychain) is detected on a website, Zen Browser on macOS attempts to autofill/use the passkey for login without providing an option to redirect or use an alternative method. This triggers the passkey API (WebAuthn), which causes all browser tabs and windows to freeze immediately. The only recovery method is to force quit the entire Zen Browser process (via Activity Monitor or Cmd+Option+Esc), close all windows, and restart the browser. Simply closing the affected tab/window or using Cmd+W does not resolve the freeze—it propagates to the entire session.

Steps to reproduce

Steps to Reproduce

1. Ensure a passkey is saved for a Google account (or similar) in Zen Browser's password manager on macOS (via Settings > Privacy & Security > Logins and Passwords).

2. Open Zen Browser with multiple tabs/windows open (e.g., research tabs in different Zen workspaces or vertical tabs enabled).

3. Navigate to or click into a site that triggers passkey detection (e.g., open a new tab and go to accounts.google.com, or visit a site like github.com that prompts for login).

4. When the browser detects the saved passkey and prompts to use it for login (no secondary options like "Use password instead" or redirect), it automatically calls the passkey API.

5. The entire browser freezes—no tabs respond, no scrolling, no switching windows or workspaces. Cmd+Tab may work, but Zen remains unresponsive.

I've attempted to isolate and resolve this locally, focusing on Zen Browser specifics:

• Tested across multiple Zen Browser versions (e.g., stable, beta – downgraded to older releases via GitHub releases).

• Switched macOS software environment from beta channel (e.g., Sonoma beta) back to default/stable (e.g., latest stable Sonoma).

• Removed all extensions (via about:addons, including Zen's bundled ones like containers or themes; tested in Private Window mode).

• Performed multiple fresh installs of Zen Browser (complete uninstall via App Cleaner or manual ~/Library removal, then reinstall from zen-browser.app or GitHub).

• Cleared browser data (cache, cookies, passwords – via about:preferences#privacy; re-saved a test passkey to reproduce).

• Tested on a clean user profile (created new macOS user account; issue persists).

• Disabled Zen-specific features (e.g., vertical tabs, workspaces via zen-settings://, and hardware acceleration via about:config > layers.acceleration.disabled = true).

• Disabled Firefox Sync and system keychain integrations (about:preferences > Sync > Pause; macOS Keychain Access > Disable autofill).

• Issue does not occur in single-tab mode or without saved passkeys; it's specifically triggered by the passkey autofill attempt. Tested in vanilla Firefox (same ESR version as Zen's base) – [does it reproduce there? If not, it's Zen-specific].

Screenshots and videos

Version

1.15.5b (Firefox 142.0.1) (aarch64)

What platform are you seeing the problem on?

macOS - aarch64

What component is this issue related to?

Security

Relevant log output if applicable

[joshuadutton]

I would appreciate any response to this since I can't use Zen for a number of things due to this bug, and I really hate switching back and forth between browsers (and I really love Zen and want it to work for me!). BTW, this crash is worse than when it didn't have passkey support. When it didn't have passkey support, I could often choose to login a different way. With the crash it disrupts everything since I need to force close and restart Zen.

I would appreciate a response like: "yes, this is a priority for us", or "this is more difficult than we anticipated, and we don't know when we will get to it", so I can plan accordingly.

[tillhfm]

This makes Zen Browser unusable on macOS at least for me but surely also for many other people out there. I cannot sing in to any Google services and thus can also not sign in to services I'm registered to with Google.
Is there any way to get around this?

[joshuadutton]

FYI, today's update makes it so the entire browser doesn't crash. Passkeys still don't work on Mac, but at least it doesn't crash, so for many sites, I can then choose to login a different way.

[schalk-conradie]

Since the last few days, I can now close the tab using cmd+W, but Zen is still unresponsive to clicks. I need to quit and re-open for things to work again. Passkeys still do not work.

[gsicvj]

Same problem. Force quitting Zen after it freezes just doesn't seem right.

[tobymac-siro]

I'm also dealing with this issue. It's a problem when I can't choose the alternative method because the browser has crashed and frozen.

[tillhfm]

Do y'all still have the issue? For me it's been resolved. I'm unsure if they fixed it or it had something to do with macOS Beta.

[gsicvj]

The issue still persists on:

• MacOS 26.1 (25B78)
• Zen 1.17.8b

[taubut]

Issue still exists. Makes the browser completely unusable.

[surranc20]

Bumping this issue