Uh oh!
There was an error while loading. Please reload this page.
fix(electron,ui): Don't run passkey autofill as a modal prompt - #9500
Conversation
The Electron passkey provider reported autofill as supported but serviced the request as a modal ceremony, so an OS passkey sheet opened as soon as the sign-in form mounted, before any user intent. - `get()` now honours `conditionalUI` instead of hardcoding it to `false`, so the renderer path performs real conditional mediation. When a conditional request would resolve to the native or unsupported path it is quietly aborted rather than prompting, and it no longer falls back to the native path on error. - `isSupported()` and `isAutoFillSupported()` now answer through the same routing rules as `decidePath()`, so they stop advertising capabilities the resolved path cannot deliver. - `SignInStart` resolves both WebAuthn predicates against the Clerk instance before falling back to the shared helpers, so a host-provided passkey provider can influence whether the autofill flow starts at all. Closes#9496
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 70a6432 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@clerk/astro@clerk/backend@clerk/chrome-extension@clerk/clerk-js@clerk/electron@clerk/electron-passkeys@clerk/eslint-plugin@clerk/expo@clerk/expo-google-signin@clerk/expo-passkeys@clerk/express@clerk/fastify@clerk/hono@clerk/localizations@clerk/nextjs@clerk/nuxt@clerk/react@clerk/react-router@clerk/shared@clerk/tanstack-react-start@clerk/testing@clerk/ui@clerk/upgrade@clerk/vuecommit: |
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
Included review availability: 5 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 6 reviews per hour. 📝 WalkthroughWalkthroughElectron passkey routing now supports conditional renderer requests and aborts conditional requests when only native routing is available. Renderer eligibility accounts for mode, origin, WebAuthn support, and legacy macOS Electron versions. Autofill support checks are asynchronous and require an eligible renderer path. Sign-in detection uses Clerk’s internal WebAuthn support APIs when available. Tests and documentation cover the updated behavior. Estimated code review effort: 3 (Moderate) | ~25 minutes Merge Risk:⚪ Minimal · up to The change updates passkey autofill routing so it waits for user intent while preserving explicit passkey sign-in behavior. No actionable merge-blocking risk remains beyond normal checks and review. Possibly related issues
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
API Changes Report
Summary
No API Changes DetectedAll packages have stable APIs with no detected changes. Report generated by Break Check Last ran on |
Uh oh!
There was an error while loading. Please reload this page.
Description
The Electron passkey provider reported autofill as supported but serviced the request as a modal ceremony, so an OS passkey sheet opened as soon as the sign-in form mounted, before user intent. On custom-scheme windows the same probe would fail with
passkey_not_supported.get()honorsconditionalUIinstead of hardcoding to false, so the renderer path performs conditional mediation. A conditional request that would resolve to the native or unsupported path is aborted and doesn't fall back to the native path.isSupported()andisAutoFillSupported()go through the same routing rules asdecidePath()& they stop advertising capabilities the resolved path cannot deliver.SignInStartresolves both WebAuthn predicates against the Clerk instance before falling back to the shared helpers, so a host-provided passkey provider can influence whether the autofill flow starts at all.Signing in with the “Use passkey” button/action is unchanged.
@clerk/electronalone does not fix the reported behaviour, the gate that starts the flow lives in@clerk/ui.Fixes#9496
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change