Repository navigation
bug(ui): Switch Provider keyboard activation can commit a provider the user did not pick #862
Description
Expected
In the Switch Provider picker, a keyboard user who Tabs to Cancel and presses Enter closes the picker. A focused button owns its own Enter — the rule components/ui/dialog-actions.tsx documents ("A FOCUSED BUTTON OWNS ITS OWN ENTER … tabbing to Cancel and pressing Enter would CONFIRM").
Actual
ProviderSwitchPickerModal's DialogContent onKeyDown handles every Enter: it calls preventDefault() (which suppresses the focused button's synthesized click) and then commits the highlighted provider row. So Tab → Cancel → Enter starts a provider switch for the targeted agent instead of cancelling.
Reproduction
- Focus an agent; run Switch Provider.
- Press Tab until Cancel has focus.
- Press Enter.
Result: the picker closes and switchSessionProvider runs for the highlighted destination.
Code evidence: src/renderer/src/features/workspace/ui/ProviderSwitchPickerModal.tsx — the event.key === 'Enter' && selected branch has no check of event.target.
Impact
A provider switch translates and replaces the conversation's runtime — not something a Cancel should ever trigger. Keyboard-only users are the ones who hit it.
Notes
Found during review of #860 (New Agent In…), whose dialog copied this pattern and had the same bug. #860 fixes both, with regression tests.
Activity
fix(ui): let a focused Cancel own Enter in the Switch Provider picker
Juliusolsson05 commentedon Sep 11, 2026
Fixed in #860 (commit 2e793b5) with a regression test in ProviderSwitchPickerModal.renderer.test.tsx; closes when #860 merges.
[-]bug(ui): Enter on a focused Cancel in Switch Provider starts the provider switch[/-][+]bug(ui): Switch Provider keyboard activation can commit a provider the user did not pick[/+]Juliusolsson05 commentedon Sep 11, 2026
Scope widened after a second review of #860. A second keyboard path commits the wrong target in the same picker: Tab to a provider row, press ArrowDown/Ctrl-N (the highlight moves, DOM focus stays on the Tab-focused row), press Space. The browser activates the FOCUSED row's native button, so the switch goes to that provider, not the highlighted one. Root cause is shared with the Enter-on-Cancel path: rows are tab stops whose focus diverges from the arrow-driven highlight. #860 fixes both paths (rows stop being tab stops, so keyboard focus is only ever on the dialog surface or the footer buttons) and adds a regression test for each.
refactor(ui): share the focused-control Enter rule from DialogActions
fix(provider-switch): keep Switch Provider rows out of the tab order