mirror of
https://github.com/GitbookIO/gitbook.git
synced 2026-09-23 02:53:29 +00:00
Claude
c2d18048f1
Browser diagnostics on the reported n8n case showed the real cause: the scroll
hooks fire when the hash is set (on link click, still on the previous page), so
`document.getElementById(hash)` misses; by the time the destination heading is in
the DOM, `scrollToHash` is never called again, so the page stays at the top. Next's
own scroll was never involved — an earlier `scroll={false}` attempt changed nothing
and is reverted here.
Make `scrollToHash` retry across animation frames (bounded to ~1s) until the target
element exists, then scroll to it once. A single in-flight retry is tracked and
cancelled if a newer scroll is requested. Hash-less navigation is unaffected
(ScrollPage scrolls to top directly, without calling scrollToHash).
Still needs a browser check: rerunning the console diagnostic should now show
`scrollIntoView` firing on the attempt where the element resolves.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TpGe6QkAF4Y1HDGUD4vbke