fix(headless): return focus to the ancestor reference when the dialog trigger is gone - #9742
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 8ebb896 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types 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 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (3)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
Included review availability: 6 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 10 reviews per hour. 📝 WalkthroughWalkthrough
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: Merge Risk: ⚪ Minimal · up to The focus-restoration change has no substantiated merge-blocking issue. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (1 skipped: 1 unsupported.)
Warning Linked repositories: Your configuration references 7 linked repositories, but your current plan allows 5. Analyzed Comment |
@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/vue
commit: |
Description
A
Dialogopened from inside aMenu(a confirmation behind a "Remove" item) has no trigger of its own that survives closing: the menu item unmounts with the menu.useReturnFocusused to handFloatingFocusManagerthat detached element, so on Escape or Close focus went to the manager's fallback guard instead of somewhere the user can see.useReturnFocusnow resolves its target lazily, when focus is actually restored. It still prefers the dialog's own trigger while that is on the page. Otherwise it walks up the floating tree to the nearest ancestor whose reference is still connected, which for a menu is its trigger button. Pointer dismissals still yieldnullsoFloatingFocusManagerkeeps its existing behaviour there.This is what lets a block like
Confirmationbe rendered insideMenu.Rootand return focus to the menu's trigger without the call site tracking a ref.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change