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

オープン
  • 何か問題がありますか？
#469 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
css, nextjs, react, typescript
領域
accessibility, frontend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
1
フォーク
1
平均マージ
6時間 56分
マージ済み PR（30日）
136

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

eddiejaoude/StackDash のほかの issue

eddiejaoude/StackDash の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。