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

Abierto
  • ¿Algo no está bien?
#469 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
css, nextjs, react, typescript
Área
accessibility, frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
1
Forks
1
Merge medio
6 h 56 min
PR fusionados (30 d)
136

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eddiejaoude/StackDash

Todos los issues de eddiejaoude/StackDash

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.