[pauljoda]

What changed

On Chromium pages, signing in with a passkey that isn't on this Mac stopped at "No passkeys available", with no way to use a phone's QR code or a security key.

• Crest sends a passkey request to the macOS system sheet first, which reaches the passkeys of every provider on the Mac. Chromium asks that sheet for this Mac's passkeys only (setShouldShowHybridTransport:false). With none for the site, macOS ends the request without showing anything, and Chromium went to its no-passkeys error.
• The engine notes and the patch comment said the system sheet offers its own nearby-device, QR and security-key fallbacks. It doesn't.

Now, when the system sheet Crest opened ends with no passkey for the site, the request goes on in Chromium's mechanism list, which offers the phone's QR code and security keys. This applies only when that list has something other than iCloud Keychain, and the request stays open meanwhile. A person's own Cancel in the macOS sheet is a separate path and behaves as before. Choosing "a passkey from another device" in a sign-in field's passkey suggestions now goes straight to that list instead of the macOS sheet, which can't offer it. The engine notes and comments are corrected.

Closes #447

#968 (Microsoft sign-in passkeys) may be this path, if the person's passkey is on a phone; that report needs more detail to say.

Engine. This changes engine inputs (Patches/native-host.patch: authenticator_request_dialog_controller.{h,cc}; host-inputs.json). It is part of a stack that ships with one engine, built and published from the top PR.

Stack, merged bottom up: #974 → #975 → #976 → #977 → #978 → #982 → #983 → #984. This is #978; the top PR carries the engine key.

Validation

• The changed hunks apply without fuzz to the pinned 156 sources and give the recorded hashes, and the engine builds.

• Not run: the positive path. Review packages don't carry the browser passkey entitlement, so they keep Chromium's own sheet and never reach Crest's system-sheet dispatch. It needs the installed development build signed with the production identity. Checklist for that build, in a Chromium tab:

  1. A site whose passkey is only on a phone (none on this Mac): sign in with a passkey. Expect Chromium's list with the phone's QR code and security key, not "No passkeys available".
  2. A site with a passkey on this Mac or in a provider such as 1Password: the macOS sheet still signs in.
  3. Cancel in the macOS sheet: same as before.
  4. In a sign-in field's passkey suggestions, choose a passkey from another device: Chromium's list opens directly.

• Gates on the stack: apply-chromium-host.py validates the host inputs and installs them, the engine builds with no work left (ninja -n), check-version.sh --fix-commit, check-public-source.py, release_note_catalog.py, check-architecture.py, audit-licenses.py, git diff --check, and the 47 script tests pass. No new tests: the engine overlay and host patch have no unit test target.

AI usage

• AI tools helped produce this change.
• I ran the crest-contribution skill (.agents/skills/crest-contribution/SKILL.md), followed it, and reviewed every generated line.

Boundaries

• Space and browsing-profile isolation are preserved.
• The macOS and mobile platform behavior remains intentionally native.
• User-visible or architecture-significant changes add an explicit entry to Documentation/ReleaseNotes.json.
• Every verified fix commit includes its patch bump and passes Scripts/check-version.sh --fix-commit.
• I have signed off every commit as described in CONTRIBUTING.md.

Summary by CodeRabbit

• New Features
  • Chromium passkey sign-in can offer a phone QR code or security key when no passkey is available on the Mac.
  • Crest integration routes supported browser actions and links through Crest while preserving link-click modifiers.
• Bug Fixes
  • macOS thumbnail capture stops when access is declined.
• Documentation
  • Clarified available passkey sign-in options and fallback behavior on macOS.
• Chores
  • Updated the app version to 0.8.186.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Chromium’s macOS passkey flow now dispatches to iCloud Keychain once. If no matching passkey is found and another mechanism remains, Chromium restarts mechanism selection. Documentation, release notes, engine input hashes, and the marketing version are also updated.

Changes: Passkey sign-in fallback

Layer / File(s)	Summary
iCloud Keychain dispatch and fallback CrestEngines/Chromium/Patches/native-host.patch, CrestEngines/Chromium/host-inputs.json	The flow dispatches to iCloud Keychain once. If no passkey is found and a non-iCloud mechanism remains, Chromium restarts mechanism selection.
Passkey behavior and release records CrestEngines/Chromium/README.md, Documentation/ReleaseNotes.json, Config/Version.xcconfig	The documentation describes the system sheet and Chromium fallback behavior. The release note records phone QR code and security-key options when the Mac has no passkey for the site. The marketing version changes to 0.8.186.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant ChromiumAuthenticatorRequest
  participant iCloudKeychain
  participant ChromiumMechanismSelection
  ChromiumAuthenticatorRequest->>iCloudKeychain: Dispatch passkey request once
  iCloudKeychain->>ChromiumAuthenticatorRequest: Report no matching passkey
  ChromiumAuthenticatorRequest->>ChromiumAuthenticatorRequest: Run OnNoPasskeys
  opt A non-iCloud mechanism remains
    ChromiumAuthenticatorRequest->>ChromiumMechanismSelection: Restart mechanism selection
  end

Loading

Possibly related issues

• pauljoda/Crest#968: This change covers passkey fallback from the macOS system sheet to Chromium’s mechanism list when no site passkey is found.

Suggested reviewers: hcbille, weensy

Merge Risk: Minimal · up to 02eff

No merge-blocking issue is confirmed. Validate the passkey flow in a signed development build.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: offering a phone or security key when Chromium cannot find a passkey on the Mac.
Linked Issues check		[#447] The patch keeps the macOS system-sheet path for Mac passkeys. When that sheet reports no site passkey, OnNoPasskeys() restarts the request only if a non-iCloud mechanism exists. Chromium can …
Out of Scope Changes check		The whole-PR diff changes the passkey controller logic and comments, the related host-input hashes, README text, version, and release note. The broad Chromium areas listed in the generated file summar…
Docstring Coverage		No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…

Full details: Linked Issues check

Explanation

[#447] The patch keeps the macOS system-sheet path for Mac passkeys. When that sheet reports no site passkey, OnNoPasskeys() restarts the request only if a non-iCloud mechanism exists. Chromium can then offer the phone QR-code and security-key mechanisms. The patch also sends an explicit request for a passkey on another device directly to Chromium's mechanism list. The reported engine build and automated gates passed. The separate Settings status and presentation findings in #447 are not required for this passkey-flow change.

Full details: Out of Scope Changes check

Explanation

The whole-PR diff changes the passkey controller logic and comments, the related host-input hashes, README text, version, and release note. The broad Chromium areas listed in the generated file summary are unchanged patch context, not changes introduced by this pull request. These changed files support the #447 passkey behavior.

Full details: Docstring Coverage

Explanation

No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)

Finishing Touches

Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 921e99c3-8211-425b-bc8f-61407c4e0d20

Commits

Reviewing files that changed from the base of the PR and between dcf39a7 and 02eff50.

Files selected for processing: 2

• Config/Version.xcconfig
• Documentation/ReleaseNotes.json

Files skipped from review as they are similar to previous changes: 1

• Documentation/ReleaseNotes.json

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 2 remain after this review.

[pauljoda]

@coderabbitai review

[coderabbitai]

Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.