Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Beta]: In the Tabbable docs demo, Tab skips the second void's buttons and Shift+Tab loops in the last void

Aperta
  • Qualcosa non va?
#5,310 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
react, typescript
Ambito
accessibility, frontend

Direzione di ricerca

Start by reading findTabDestination in packages/platejs/src/tabbable/react/TabbableEffects.internal.tsx and compare its path handling for a caret inside a void node with the reported tab stops. Reproduce the sequence in the Tabbable docs demo across the listed browsers. Done means Tab and Shift+Tab visit each void’s buttons once in document order and can leave the editor at either end.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

a11y bug target:beta triaged

Testing lane

  • Repository: udecode/plate
  • Branch: next
  • Release channel: Beta
  • Exact commit/package version: NOT_ENOUGH_INFO

Summary

https://beta.platejs.org/docs/tabbable says the Tabbable plugin handles tab order for void nodes. In its demo, Tab goes through the first void's Button 1 and Button 2, then puts the caret on the second void, then jumps to the third void's buttons. The second void's buttons are never reached. Shift+Tab from the end goes back through the third void's buttons, into that void, and then to the same buttons again, in a loop. platejs.org's demo also loops, in a different way, so it is not a passing baseline.

Reproduction

Repro 1: Tab and Shift+Tab, Firefox

An agent ran this in Firefox 158 on macOS on 2026-10-21, for Sin's assigned pages, and recorded it.

  1. Open https://beta.platejs.org/docs/tabbable.
  2. Click Button 1 in the first void, then press Tab four times.
  3. Click Button 2 in the third void, then press Shift+Tab six times.

Results:

  • Step 2: Button 2 of the first void, then the caret on the second void with neither of its buttons focused, then Button 1 and Button 2 of the third void.
  • Step 3: Button 1, then the caret on the third void, then Button 2 again, and the same three stops repeat.

Five clean page loads gave the same order. At the time Sin judged the order acceptable. natamox judged it a bug on 2026-10-24.

Repro 2: Chromium and WebKit

An agent ran this on the live Beta in headless Chromium 149 and WebKit 26.5 (Playwright) on 2026-10-24. There is no recording.

  1. Click the end of the paragraph Properly handle tab orders for void nodes….
  2. Press Tab eight times, then Shift+Tab eight times.

Tab stops in both engines: first void Button 1, Button 2, the caret in the second void, third void Button 1, Button 2, the caret in the paragraph after the third void, then out of the editor. Shift+Tab, after one or two stops at the end of the editor, reaches the third void's Button 2, Button 1 and the caret in the third void, then Button 2, Button 1 and the caret in the third void again.

Expected

Tab and Shift+Tab visit each void's buttons in document order, and leave the editor at either end, as the page says the plugin does.

Actual

Forward Tab skips the second void's buttons, and Shift+Tab loops inside the last void.

Environment

  • Exact next commit/Beta package version: NOT_ENOUGH_INFO. The page does not show its build.
  • Repro 1: Firefox 158 on macOS, 2026-10-21.
  • Repro 2: Chromium 149.0.7827.55 and WebKit 26.5 (Playwright, headless) on macOS, 2026-10-24.
  • Not tried in Safari itself or on a phone.

Caveat

From a reading of findTabDestination in packages/platejs/src/tabbable/react/TabbableEffects.internal.tsx on next a32ed63c78:

  • From a void's last button, Tab moves to the point after the void (:33), and Shift+Tab to the void's own point (:38). The caret then sits in a void's text leaf, at a path such as [4, 0].
  • From a caret, it picks the next stop by comparing each void's path with the selection path (:51-64). For a void at [4] against a caret at [4, 0], PathApi.compare returns 0 and the length tie-break gives -1. So forward Tab counts the void as already passed and skips its buttons, and Shift+Tab counts it as before the caret and picks its last button again.
  • This likely explains both symptoms, but it is inferred from reading and not tried as a code change.

Evidence

  • Repro 1: the agent's recording, 0:30, with English captions. Steps are sampled, Beta and platejs.org were driven separately and aligned by step, and some frames are held. A record number in the caption is covered.
Repro 1 — Firefox 158, /docs/tabbable (Beta and platejs.org)

https://github.com/user-attachments/assets/58333b70-3f03-4c98-8954-7989d1aeaa50

Related

  • #5199: Tab moves focus out instead of indenting where the toolbar Indent button works.
  • #5261: Shift+Tab cannot move focus out of an external text textarea.
Lingua principale
TypeScript
Stelle
16.6k
Fork
993
Merge medio
20h 1m
PR unite (30g)
60

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di udecode/plate

Tutte le issue di udecode/plate

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.