fix(web): stop project-scope menu from highlighting first row without hover

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[IzonIcy]

What changed

apps/web/src/components/Sidebar.tsx: when the sidebar project-scope menu ("All projects" dropdown) is opened with a pointer, focus is redirected to the popup element itself during commit. Base UI's open-time autofocus — which queues a microtask and skips when focus already sits inside the popup — then no-ops instead of landing on the first tabbable element, the settings gear inside the first project row.

Keyboard opens keep Base UI's default behavior (the checked row is pre-highlighted and receives focus itself). Arrow-key navigation, Tab-to-gear, and mouse clicks on the gear are unchanged; only the misdirected open focus moved.

Why

Fixes#7915: opening this menu with the mouse rendered the first project row as highlighted although the pointer was elsewhere, because every row is tabIndex=-1 until highlighted and focus bubbling into the gear marked its row active.

Evidence

Menu opened with the pointer, nothing hovered.

Before — the t3-demo-project row renders highlighted because Base UI's open autofocus landed on its settings gear:

After — focus lands on the popup itself; the project row stays neutral (the checked "All projects" row keeps its selection background, as intended):

Images live on the fork's pr-evidence/7950 branch so no PR-only assets land in the repo.

Verification

• Scoped typecheck clean (tsgo --noEmit, 0 errors); lint clean
• Focus-redirect mechanics verified against Base UI 1.5.0 internals (FloatingFocusManager skips its queued autofocus when focus is already inside the floating element)

--
Worked by ox-alpha via opencode (x-preview-f-free).

Note

Fix project-scope menu highlighting first row when opened by pointer

• Adds a projectScopeOpenedWithPointerRef in Sidebar.tsx set via onPointerDown/onKeyDown on the menu trigger, distinguishing pointer opens from keyboard opens
• Adds a FocusPopupOnMount component and optional focusOnMountRef prop to MenuPopup in menu.tsx; when enabled, the popup element itself receives focus on mount instead of the first tabbable descendant
• When the project-scope menu is opened with a pointer, the popup is focused to avoid pre-highlighting the first row; keyboard opens retain the default focus behavior

^{Macroscope summarized 3a0f2aa.}

---

Note

Low Risk
Localized focus-management workaround for one menu; keyboard behavior and other menus are unchanged unless they opt into focusOnMountRef.

Overview
Fixes incorrect row highlight when the sidebar All projects menu opens via click: Base UI autofocus was landing on the first row’s nested settings gear instead of leaving rows neutral.

MenuPopup gains an optional focusOnMountRef and a FocusPopupOnMount layout effect that focuses the popup container (with preventScroll) when the ref is true at mount, so Base UI’s focus manager skips autofocus to the first tabbable descendant.

Sidebar records pointer vs keyboard on the project-scope trigger (onPointerDown / onKeyDown) and passes that ref into MenuPopup so pointer opens redirect focus to the popup; keyboard opens keep the default pre-highlighted checked row.

^{Reviewed by Cursor Bugbot for commit 3a0f2aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad38b52-28e7-4308-a0c5-3cdefa322497

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the open-focus redirect is a component-local workaround that depends on Base UI's internal focus timing, while the actual cause (a tabbable Button nested inside a menu radio item) is left in place. Details inline.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Fixed in 437a995 — the timing critique was fair, so the redirect moved from a Sidebar-level layout effect into the popup's own subtree: a hidden sentinel child focuses [data-slot='menu-popup'] during its layout effect, which React runs before the popup component's FloatingFocusManager effect (child-first). The manager therefore snapshots activeElement already inside the floating element and skips its queued autofocus outright — no dependency on which commit the popup mounts in, and no reliance on the enqueueFocus shouldFocus re-check. The sentinel only mounts for pointer-opened menus; keyboard opens keep Base UI's default pre-highlighted-row focus.

[macroscopeapp]

Reviewed the project-scope menu focus fix against the shared Menu primitive contract and Base UI 1.4.1 behavior. The layout-effect ordering the sentinel relies on does hold in 1.4.1 (FloatingFocusManager snapshots activeElement synchronously in its own layout effect and bails when focus is already inside the popup), so the mechanism itself is sound. Three smaller issues remain: a render-time ref read that the React Compiler rejects, a popup focus() call that does not mirror Base UI's preventScroll, and ownership of the behavior sitting at one call site while an identical menu composition exists elsewhere.

^{Posted via Macroscope — UI Consistency}

[IzonIcy]

Before (main): opening the project-scope menu highlights the first project row even though the pointer never left the trigger.

After (fix branch): identical interaction — no row is highlighted until the pointer or keyboard actually touches one.

Both captured on an isolated dev environment — same machine, same seeded project, menu opened with a mouse click each time. For extra rigor: on main, DOM inspection confirms the project row ends up data-highlighted=true with focus stolen from the trigger; with the fix, focus stays on the popup element and no item receives data-highlighted. Keyboard opens are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 437a995. Configure here.}

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused, opt-in UI focus correction limited to the project-scope menu, with keyboard behavior and other menus preserved. An unresolved Medium finding identifies a popup-ref merging risk, which remains a separate correctness gate under the repository’s configured threshold.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

🟡 Mediumui/menu.tsx:103

When a caller supplies ref, {...props} overwrites popupRef, so FocusPopupOnMount sees popupRef.current === null and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/components/ui/menu.tsx around line 103:
When a caller supplies `ref`, `{...props}` overwrites `popupRef`, so `FocusPopupOnMount` sees `popupRef.current === null` and the opt-in popup is not focused; the caller's ref is also the only ref attached. Merge the internal and caller refs instead of allowing the spread to replace the internal ref.
Evidence trail:
3fe9398
apps/web/src/components/ui/menu.tsx:25-40
apps/web/src/components/ui/menu.tsx:54-108
apps/web/package.json:15,42

[IzonIcy]

Attaching the before/after captures promised in the description (hosted on the fork's pr-evidence/7950 branch to keep PR-only assets out of the repo):

Before — pointer open, no hover: t3-demo-project row wrongly highlighted (autofocus landed on its gear):

After — pointer open: focus lands on the popup, project row neutral:

[macroscopeapp]

Two findings in the shared MenuPopup primitive. The behavior goal (no pre-highlighted row on pointer opens) looks right; the concern is where the behavior lives and how it is wired.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This puts popup focus ownership in a hidden child whose correctness depends on React running its layout effect before Base UI's focus manager, and it pushes interaction-type detection out to every consumer (Sidebar.tsx now tracks onPointerDown/onKeyDown on the trigger by hand). Base UI's popups already own both halves of this: Menu.Popup accepts initialFocus — the sibling of the finalFocus prop this repo already uses on a Base UI popup in CommandPalette.tsx:535 — as a ref or a callback that receives the open interaction type, and the focus manager consults it instead of being raced by effect ordering.

Suggest replacing FocusPopupOnMount + focusOnMountRef with initialFocus on MenuPrimitive.Popup, returning popupRef.current for non-keyboard opens and falling through to the default for keyboard opens (verify the exact callback return contract with a typecheck against @base-ui/react@1.5.0). That keeps the fix declarative, survives Base UI upgrades that change when the focus manager runs, and lets MenuPopup apply it by default — the same nested-control-in-first-row pattern exists at ProjectScriptsControl.tsx:214, which the current opt-in ref prop does not cover.

No diff: the fix spans the prop signature and the Sidebar trigger handlers.

^{Posted via Macroscope — UI Consistency}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing this alternate menu focus policy. The same project-menu highlight is covered by #7916. This version adds a shared layout-effect focus API and relies on open-time scheduling details. Keep the pointer-versus-keyboard reproduction in the selected fix and use the menu primitive's supported initial-focus behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.