Skip to content

Restore the selected tab as the keyboard entry point - #860

Open
obaseyi2 wants to merge 1 commit into
jupyterlab:mainfrom
obaseyi2:fix/tab-keyboard-entry
Open

obaseyi2 wants to merge 1 commit into
jupyterlab:mainfrom
obaseyi2:fix/tab-keyboard-entry

Conversation

@obaseyi2

@obaseyi2 obaseyi2 commented Oct 25, 2026 •

Copy link
Copy Markdown

Fixes #618.

The tab bar keeps the previous DOM index as its keyboard entry point after selection/reordering. Arrow-key browsing can also leave an unselected tab as the entry point after focus exits.

Synchronize tabindex after rendering and focus transitions: use the selected tab when focus is outside, preserve the focused item while navigating inside, and retain first-tab/add-button fallbacks. This changes neither selection nor focus automatically. Changes are in tabbar.ts and its tests.

Reproduction

  1. Create three tabs, select the third, and focus a button before the bar.
  2. Press Tab: focus should enter the third tab.
  3. Press Left Arrow to browse the second tab without selecting it.
  4. Press Tab to leave, then Shift+Tab: focus should return to the selected third tab.
  5. Move the selected title to the first position and repeat entry: focus should follow that title.

Validation

  • Widget suite: 984 tests passed in each of Chromium and Firefox.
  • Original source failed six regression tests in Chromium.
  • Eight native-key checks passed in each browser, including DockPanel content traversal and reorder.
  • Widgets build/bundling, changed-file lint/format and diff whitespace checks passed.

WebKit and full JupyterLab were not tested.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tab and Shift+Tab are moving the focus in strange way in DockPanel

1 participant