Tabbing forward through an open modal dialog briefly moves keyboard focus out of the dialog and onto the app navigation behind it. The next Tab returns focus to the dialog's first control. A modal dialog should keep focus inside it.
Found while validating #170 / #171. The same sequence happens before and after that change, so it is pre-existing and was not changed there.
Reproduce
- Open Ace in a browser at 1440×900 with any project, and open Settings (Ctrl/Cmd+,).
- Press Tab repeatedly past the last control (Close).
Observed Tab sequence from Close onward (in/OUT = whether document.activeElement is inside [data-slot=dialog-content]):
5194bf7: in:Close > OUT:SPAN > OUT:Dashboard⌘1Channels⌘2… > in:Providersb11535a: in:Close > OUT:SPAN > OUT:Dashboard⌘1Channels⌘2… > in:General
The SPAN is the dialog's focus guard. The next stop is the app's left navigation (Dashboard/Channels/Issues/PRs). Only after that does focus wrap back to the dialog's first control.
Observed in headless Chrome with real Tab key events sent over the DevTools protocol, against a source host. The native WebKit app was not checked. Evidence: /tmp/ace-ui-refresh-20261006/settings-evidence/tabtest.ts on natembp.
Expected
Tab and Shift+Tab cycle only among the dialog's controls while a modal dialog is open. Content behind the dialog is never focusable. This applies to every consumer of the shared packages/ui dialog: Settings, Open Project and Rename.
Related
#44 covers controls that stay reachable while the desktop sidebar is collapsed. This issue is about modal focus containment, not collapsed layout state.
Tabbing forward through an open modal dialog briefly moves keyboard focus out of the dialog and onto the app navigation behind it. The next Tab returns focus to the dialog's first control. A modal dialog should keep focus inside it.
Found while validating #170 / #171. The same sequence happens before and after that change, so it is pre-existing and was not changed there.
Reproduce
Observed Tab sequence from Close onward (
in/OUT= whetherdocument.activeElementis inside[data-slot=dialog-content]):5194bf7:in:Close > OUT:SPAN > OUT:Dashboard⌘1Channels⌘2… > in:Providersb11535a:in:Close > OUT:SPAN > OUT:Dashboard⌘1Channels⌘2… > in:GeneralThe
SPANis the dialog's focus guard. The next stop is the app's left navigation (Dashboard/Channels/Issues/PRs). Only after that does focus wrap back to the dialog's first control.Observed in headless Chrome with real Tab key events sent over the DevTools protocol, against a source host. The native WebKit app was not checked. Evidence:
/tmp/ace-ui-refresh-20261006/settings-evidence/tabtest.tson natembp.Expected
Tab and Shift+Tab cycle only among the dialog's controls while a modal dialog is open. Content behind the dialog is never focusable. This applies to every consumer of the shared
packages/uidialog: Settings, Open Project and Rename.Related
#44 covers controls that stay reachable while the desktop sidebar is collapsed. This issue is about modal focus containment, not collapsed layout state.