signTypedDataAsync returns undefined when using password manager passkey authentication

[ulixes]

Check existing issues

• I checked there isn't already an issue for the bug I encountered.

Describe the bug

When using Porto in dialog mode (both iframe and popup), signTypedDataAsync (and similarly signMessageAsync) resolves with undefined instead of the expected signature, even after the user successfully completes the signing process in the UI (including passkey auth). No JavaScript errors are thrown, and the UI indicates success. The promise resolves, but the result is undefined. This appears to be due to queued.result being undefined despite queued.status being 'success' in dialog.ts. I do not intend to submit a PR.

Link to Minimal Reproducible Example

https://github.com/ulixes/porto-signing-bug

Steps To Reproduce

1. Clone the repo: git clone https://github.com/ulixes/porto-signing-bug
2. Install dependencies: bun install
3. Start the dev server: bun dev
4. Open the app at http://localhost:5173/
5. Click "Connect Wallet" and connect using Porto
6. After connection, click "Sign In"
7. Complete the passkey auth and approve the signature in the Porto dialog
8. Check the browser console: the signature logs as undefined despite UI success

Porto Version

0.2.23

Viem Version

2.37.9

Wagmi Version

2.17.5

TypeScript Version

5.5.4

Anything else?

• Browser: Chrome (latest)
• OS: Linux
• Chain: Base Sepolia (84532)
• Node: v20.18.3
• Package manager: Bun 1.2.20
• The bug is consistent across dialog modes and affects SIWE authentication flows. No workarounds found.

[jxom]

Unable to reproduce.

[ulixes]

@jxom I confirmed this with another user - the issue occurs specifically when using password manager passkey authentication (1Password, Google Password Manager, etc.).

In this flow:

1. Porto triggers passkey → password manager prompts (often via QR code on cross-device)
2. User completes passkey auth on phone/device
3. Porto UI shows success
4. signTypedDataAsync resolves with undefined

This is reproducible with the provided repo when using password manager passkey flows. Can you reopen this issue and test with a password manager-based passkey?

[ulixes]

@jxom This issue seems to have been closed as "not planned," but I've confirmed it's reproducible specifically with password manager passkey flows (e.g., 1Password or Google via QR/cross-device), as per my earlier comment. It's impacting SIWE auth workflows. Could you please reopen and investigate? Happy to provide more details or test fixes.