[Beta]: Tab and Shift+Tab leave table cells instead of navigating

[felixfeng33]

CleanShot.2026-08-04.at.17.18.46.mp4

Pressing Tab or Shift+Tab in a table cell moves browser focus out of the editor instead of navigating horizontally. The editor selection remains in the original cell.

This reproduces on both current surfaces:

• deployed homepage (main behavior): 2/2 clean runs
• local next at 2938677: 2/2 clean runs

Current origin/main is 45116fd. Its table keydown handler has no Tab/Shift+Tab path, matching the deployed behavior. next routes these keys through update.tab(), but the homepage still loses focus.

Expected behavior

Tab moves to the next table cell and Shift+Tab moves to the previous cell. Notion documents horizontal Tab navigation for simple tables: https://www.notion.com/en-gb/help/guides/simple-tables-vs-databases

Reproduction

1. Open the homepage editor.
2. Click inside the AI table cell.
3. Press Tab.
4. Click inside the checkmark cell.
5. Press Shift+Tab.

Actual: focus moves to an editor UI button while the native selection stays in the same cell. No console errors are emitted.

Regression context: #1793 described the same focus-leaving behavior and was closed as completed; #413 originally added Tab/Shift+Tab table navigation.

Video is attached above.

[dosubot]

This is likely caused by TabbablePlugin intercepting the Tab keydown event before the table's tab transform can run.

The table plugin implements Tab/Shift+Tab navigation as a transform override in withTable.ts — it calls getNextTableCell/getPreviousTableCell and moves selection accordingly. However, TabbablePlugin attaches a raw DOM keydown listener (with capture: true) that intercepts Tab events first [1]. When it finds no tab destination, it sets all tabbable nodes to tabindex=-1 and lets the browser move focus out of the editor entirely [2]. This prevents the table transform from ever executing.

The fix would be to make TabbablePlugin's query option aware of table context — returning false when the selection is inside a table cell so that Tab events fall through to the table transform instead. Alternatively, the event handler ordering could be adjusted so the table plugin's tab logic runs before TabbablePlugin.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[zbeyens]

Fixed locally and verified.

Root cause: Plate shortcuts were dispatched before the live DOM selection was synchronized into editor state. Table Tab handling could therefore act on a stale selection and lose to generic Tab shortcuts. TabbablePlugin is not installed in the reproduced editor, so it was not the cause.

Local patch:

• dispatches shortcuts inside the synchronized editable keyboard pipeline while preserving existing prevention and propagation behavior
• gives table-owned Tab and Shift+Tab navigation priority over generic indentation shortcuts
• adds stale-selection regression tests for both directions

Proof:

• @platejs/core: typecheck passed; 700 tests passed
• @platejs/table: typecheck passed; 239 tests passed
• Browser /view/editor-ai: Suggestions → ✅ with Tab, then ✅ → Suggestions with Shift+Tab; focus remained in the editor
• final P2 autoreview: clean

This is still local only: no commit, push, or PR exists yet, so the issue should remain open.