feat(web): a bindable command opens the sidebar's project filter#27158

External image Major · Functional Correctness · Heavy lift

Register the shortcut outside the mobile sheet.

On a narrow viewport, ThreadSidebar is inside the mobile sheet. The sheet unmounts its children when closed, so this handler is not registered. A hardware-keyboard user cannot open the closed sidebar with this shortcut. Register the command in the persistent shell and open the mobile sheet before the picker. (raw.githubusercontent.com)

External image Minor · Functional Correctness · Quick win

Pass terminal and preview state to the project filter shortcut.

The sidebar.filterByProject registration does not pass a context option. Without one, the dispatcher uses the default false for terminalOpen and previewOpen. A keybinding with when: "terminalOpen" for this command therefore does not match in this scope, even when the terminal is open. The same applies to previewOpen.

Supply both values through the registration's context option. Read them when the event fires. The effect registers with [onFilterByProjectShortcut] only, so it does not re-run when the route or panel state changes. Sidebar.tsx already derives routeTerminalOpen for its thread-navigation listener. AppSidebarLayout.tsx passes readRoutePanelsOpen(router) as a context getter for its registrations.

This affects only user-configured when clauses. The command has no default binding.

Fixed the context part in 56cd06c9d4. The registration now passes terminalOpen and previewOpen, read when the key is pressed, as the app shell's scopes do. On the web dev build, a when: "terminalOpen" binding for this command did not fire with the terminal open before the change, and fires after it. With the terminal closed it still does not fire.

@serge-the-hedge The supplied code now passes readRoutePanelsOpen as the registration’s context getter. This addresses the context finding. Your reported check also confirms that when: "terminalOpen" matches only while the terminal is open.

The mobile-sheet finding is separate and remains unaddressed by this change, so this combined thread should stay open.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

_{You are interacting with an AI system.}

Leaving the closed drawer out of this PR, as its Scope and approval section says. Below 768 CSS px with the drawer closed, the sidebar is not mounted, so the key does nothing. mod+B opens the drawer, and the shortcut then works. Covering that state means moving the picker's state out of the sidebar into the app layout, which is a larger change than this command justifies. Nothing regresses, because this state has no shortcut today.

@serge-the-hedge Understood. The closed mobile drawer is an explicit scope exclusion, not a regression. I withdraw the request to move the command registration into the app layout for this PR.

Below 768 CSS px, users can open the drawer with mod+B, then use the project-filter shortcut. The separate context finding is already addressed.

Would you like a follow-up GitHub issue for opening the project filter directly from the closed mobile drawer?

✅ Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Preserve focus on outside clicks.

The finalFocus function is used for every close, including an outside click. Base UI 1.5.0 treats a function as explicit return focus, even when it returns true. Clicking another input can therefore move focus back to the filter button or the previously focused element. Restore focus only for the close actions that require it; let outside clicks keep their destination. (raw.githubusercontent.com)

Based on learnings: skip focus restoration when focus moves away naturally.

Source: Learnings

Not reproduced on 56cd06c9d4. On the web dev build in headless Chromium, I opened the picker by mouse and by shortcut, then either clicked thread Search or pressed Tab. In all four cases the picker closed and focus stayed where the user moved it: thread Search after the click, Add project after Tab.

@serge-the-hedge Your four checks cover both opening methods and both ways of moving focus away. The reported results contradict the focus regression I claimed on 56cd06c9d4.

I inferred the behavior from finalFocus without establishing the full close behavior. I withdraw this finding. No change is needed for this comment.

✅ Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Preserve rule precedence with composer focus.

When the terminal is open and the composer has focus, a sidebar.filterByProject rule conditioned on terminalOpen can override a later rule conditioned on composerFocus. The dispatcher does not receive composerFocus in this scope, so it selects the filter rule and consumes the key before ChatView can run the later rule. Supply the context needed to resolve competing rules consistently. (raw.githubusercontent.com)

Not changing this here. The behavior needs two hand-written rules on one chord, and it does not depend on this command: any scope resolves a chord with only the context it has, so composerFocus is visible only where the composer supplies it. No default binding is affected. Default chords shared across scopes split on keys the dispatcher supplies to every scope, such as terminalFocus and modelPickerOpen. A fix would belong in a shared dispatcher context, not in this registration.

@serge-the-hedge Understood. I withdraw the request to add composerFocus to this registration. My finding treated a cross-scope context limitation as a defect specific to sidebar.filterByProject.

A consistent fix belongs in the shared dispatcher context, not in this command’s registration. No change is required here for this finding.

Would you like me to open a follow-up issue for shared-context rule precedence?

✅ Review thread resolved.

_{You are interacting with an AI system.}