docs/solutions/ui-bugs/2026-05-25-docs-sidebar-active-scroll-needs-dom-current-query.md
The docs sidebar can look visually correct while still opening deep pages with
the active item hidden below the fold. A ref attached through next/link is not
the most reliable source for active-scroll handoff in this docs sidebar.
/docs/components/ai-menu rendered the correct active AI Menu link, but the
sidebar stayed at scrollTop: 0.Link and calling
scrollIntoView. The active DOM node existed, but the effect did not reliably
get the element and the sidebar did not move.scrollIntoView choose the scroll container. The docs page has a
nested sidebar scroller, so relying on the browser to pick the right container
is fragile.Mark the real sidebar scroll container in the docs layouts:
<div className="scrollbar-hide h-full overflow-auto" data-docs-sidebar-scroll>
<DocsNav sidebarNav={sidebarNav} />
</div>
In DocsNav, keep a ref on the nav root and query the rendered current link
after route changes:
const activeElement = navElement?.querySelector<HTMLAnchorElement>(
'a[aria-current="page"]'
);
Then scroll the nearest [data-docs-sidebar-scroll] container explicitly:
const offset =
itemRect.top -
areaRect.top -
scrollArea.clientHeight / 2 +
itemRect.height / 2;
scrollArea.scrollTo({
top: Math.max(0, scrollArea.scrollTop + offset),
});
aria-current="page" is the rendered truth for the exact active route. Querying
that DOM state avoids depending on ref forwarding through a framework link
component, and scrolling the marked container avoids accidentally moving the
document body or doing nothing when the active link sits inside a nested
overflow area.
aria-current the browser-verifiable active route
marker./docs, after sidebar changes.scrollTop, and no full-page scroll jump.