mirror of
https://github.com/GitbookIO/gitbook.git
synced 2026-09-21 01:53:26 +00:00
Claude
2e182fd111
Browser diagnostics on the reported n8n case showed two cooperating causes, which is why the earlier single-sided attempts failed: 1. The scroll hooks fire when the hash is set (on link click, still on the previous page), so the target heading isn't in the DOM yet and scrollToHash missed and never retried. Fixed in the previous commit by retrying scrollToHash across frames. 2. With the retry in place, our scrollIntoView *does* fire once the heading commits — but Next's own post-navigation scroll (its hash scrollIntoView plus a scroll-to-top, see useHash / vercel/next.js#49465) runs after us and wins, snapping back to the top. Set `scroll={false}` on the internal NextLink so Next stops managing scroll on client-side navigation and GitBook's ScrollPage/useScrollToHash own it exclusively: retry to the hash when present, scroll to top otherwise. Neither change works alone — the retry needs Next to stop overriding it, and scroll={false} needs the retry to find the late-committing element. Still needs a browser check: rerunning the console diagnostic should now show our scrollIntoView fire without a following scroll-to-top, landing on the heading. Because scroll={false} routes all navigation scroll through ScrollPage, also regression-check plain page-to-page nav (top), same-page anchors, and back/forward. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TpGe6QkAF4Y1HDGUD4vbke