fix(web): keep in-page jumps from being dropped during a smooth focus scroll

Aperta
  • Qualcosa non va?
#469 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
Mezza giornata
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
css, nextjs, react, typescript
Ambito
accessibility, frontend

Direzione di ricerca

Start with src/app/globals.css around line 55, where scroll-behavior: smooth is set, and read pull request #468 to see how the e2e helper now waits for scrolling to settle. Reproduce by serving the page in Chromium, throttling the CPU to 8x, tabbing to a below-the-fold in-page link and pressing Enter within ~500 ms — the URL fragment changes but the target stays out of view. The maintainer has not chosen between re-scrolling on scrollend/hashchange and making jumps instant, so confirm the approach before writing code; done means the target is reached under 8x throttling and prefers-reduced-motion behaviour is unchanged.

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

Descrizione

area: web bug impact: low priority: P3 size: S

Context

html has scroll-behavior: smooth (src/app/globals.css:55), so every focus change that scrolls the page and every in-page jump animates. On a busy main thread, Chromium can drop an in-page jump that starts while a focus scroll is still running: the URL changes to the fragment, and the page stays at the link instead of moving to the target. A keyboard user on a slow or busy device who presses Enter on an in-page link within about half a second of tabbing to it can land there.

Found while fixing the flaky e2e test in #467 (pull request #468). Evidence from the Fable review on #468, in bare Chromium 156 on a static page with no app code (html { scroll-behavior: smooth }, a link below the fold, Tab to it, then Enter after a fixed delay):

CPU Enter pressed Target in view
1x 0 to 1200 ms after focus 24 of 24
8x throttle 0 to 500 ms after focus, during the roughly 540 ms focus scroll 12 of 18
8x throttle 800 and 1200 ms after focus 6 of 6
8x throttle 0 ms, without scroll-behavior: smooth 2 of 2

After #468, the e2e helper waits for scrolling to settle, so no spec shows this any more.

Decision for Eddie

Option Pros Cons Effort Impact
Keep smooth scrolling, re-run the jump after the focus scroll ends (for example, on hashchange, scroll the target into view once scrollend fires) Keeps the current feel Client code on the docs and landing pages; another moving part S Keyboard users on slow devices always reach the target
Make only in-page jumps instant (scroll-behavior: auto, keep smooth for nothing) Removes the race entirely; less motion Section links on the landing page stop animating XS Same fix; motion change for everyone
Status quo Nothing to do The jump can be lost on slow devices XS Rare: needs a busy main thread and Enter within about half a second of Tab

Acceptance criteria

  • Enter on an in-page link reaches its target even when pressed during a focus scroll under 8x CPU throttling.
  • prefers-reduced-motion behavior unchanged.

Files and areas

src/app/globals.css, possibly a small client handler for in-page links.

Model: anthropic/claude-opus-5-5 | Reasoning effort: unknown

Lingua principale
TypeScript
Stelle
1
Fork
1
Merge medio
6h 56m
PR unite (30g)
136

Preparare l'ambiente

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 eddiejaoude/StackDash

Tutte le issue di eddiejaoude/StackDash

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.