9b9012d23da5c4316ae5930e59498f56f546c058
Clicking any link shifted the whole app up by ~70px: the top of the content slid behind the fixed header, and the nav dock — which should stay hidden until you reach for it — appeared at the bottom. It survived navigation and only a full reload cleared it. `overflow-hidden` still makes an element a scroll container; it only hides the scrollbar. The nav Dock is absolute inside this section and hides itself with translateY(calc(100% + 24px)), and a transformed descendant contributes its transformed box to the scrollable overflow area — so the section had ~70px of scrollable range it was never meant to have. Clicking a link moves focus, the browser scrolls the nearest scroll container to reveal the focused element, and everything inside (all of it absolute inset-0) went up with it, the parked dock included. overflow-clip clips identically but does not create a scroll container, so there is nothing for focus-into-view to scroll. Diagnosed from the running app rather than by reading: the section reported scrollTop=70 at the moment the layout was wrong, matching the 70px the content and the music bar had moved, while innerHeight/visualViewport stayed at 556 (ruling out the dvh/URL-bar theory) and the outer div's scrollHeight equalled its clientHeight (ruling out the shell). Confirmed fixed in the browser. The outer div at :21 is also overflow-hidden and is left alone — it has no scrollable overflow, so it cannot exhibit this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Description
No description provided
42 MiB
Languages
TypeScript
90.9%
Shell
4.7%
JavaScript
4.1%
CSS
0.2%
HTML
0.1%