Repository navigation
Description
Describe the problem that you experienced
Problem
On Safari (desktop - tested on OS 26) - The original shell sets overflow: hidden on body to lock scroll when the mobile nav opens. This removes the scrollbar, causing an 8 px layout shift as the scrollbar gutter disappears. This instantly changes the viewport width, which:
- Triggers CSS media query breakpoint changes mid-animation
- Causes content to reflow and jump
- Is especially severe on Safari, where body is the scroll root by default
Here are 2 images to show the bug:
Note the top image gives one width, when enabling the menu and hiding the scrollbar, the second shows the new width which triggers the 700px media query with a new reported width.


Enter the URL of the topic with the problem
Describe what you were looking for in the documentation
No response
Describe the actions that led you to experience the problem
I was testing another bug when setting to 700px exactly would expose a previous media query collision.
Describe what you want to experience that would fix the problem
Move the scroll root from body to html by setting overflow-y: scroll on the html element. The persistent overflow-y: scroll keeps the scrollbar gutter reserved at all times — even when scroll is locked — so the viewport width never changes and media queries never fire at the wrong breakpoint. (Additionally you'd need some cleanup as some other elements will break and need fixing. Like you may need to scroll spy and return scroll, you also may need to ditch scroll: smooth when you capture and restore scroll positions (because when you enable overflow: hidden your content will jump to top 0)
Add a screenshot if that helps illustrate the problem
No response
If this problem caused an exception or error, please paste it here
If the problem is browser-specific, please specify the device, OS, browser, and version
Safari with mouse (desktop) so that you get visible scrollbars.
Provide any additional information here in as much as detail as you can
I was playing around with the site and I've fixed alot of the bugs at
https://dev.zadesigns.com (at the time of this report) but I also switched to ui-router and made a few other tweaks (fixed animation and other things) so it may not be a 100% help.. but at least you can see what i envisioned as a fix.
Activity
zurie commentedon Jun 5, 2026
this does not fix the issue for me on Safari on a Desktop Mac (not a mobile issue)
On desktop safari (I am on Version 26.5 (21624.2.5.11.4) if you put your browser at 698 pixels wide. and you click the hamburger menu, the screen changes from 698px to 706px
698px + 8px = 706px. (The scrollbar is 8px)
I also originally tried to put "scrollbar-gutter: stable;" on the body when I was researching a fix but it did not change or resolve the bug.
Are you suggesting that this is a Safari Bug and needs to be filed with apple?
hawkgs commentedon Jun 11, 2026
@zurie, not that it matters a lot, but is this bug limited to Safari? Just asking if you've tried that. It does seem like something reproducible in all/most browsers. I'm almost certain about Chrome.
Ps. I don't have a mouse at hand right now to verify.
zurie commentedon Jun 11, 2026
So on Windows 11 with Brave when you are at 696 px (just under 700px) and you expand the menu, you do see a tiny "push" over of the content itself, but you don't have the main menu break.
But specifically on Mac OS with Safari on Desktop... if you goto 696px and you hit the menu, it physically recalculates the width and sends it to your CSS / JS. so now your browser is telling your media queries its 704px and it physically switches the hamburger menu into a horizontal menu. (broken)
then, you CLOSE the menu and the scrollbar returns and you are recalculating back to 696px and the screen again changes the menubar from a horizontal one back to the hamburger menu.
That's why I was suggesting this is a safari desktop bug potentially?
Also, on iPAD in the latest release you can resize your windows to be any size you want, and there is no menu shift there at all, its perfect, so it really makes me feel like its the way safari desktop handles the scrollbars and in turn causes the layout issues I've explained above.
hawkgs commentedon Jun 12, 2026
Thanks for the provided information. I thought it's a pure classic vs. overlay scrollbar issue.
fix(docs-infra): stabilize html element scroll gutter
fix(docs-infra): stabilize html element scroll gutter
zurie commentedon Jun 18, 2026
Just so we are clear, whatever fix we did (probably adding scroll-gutter:stable to both body and HTML) now does
Screen.Recording.2026-06-18.at.12.03.37.PM.mov
the reverse...
it now removes 8px from the browser calculation when you hide the scrollbar.
so if you set your browser to 703px. Click a menu (in safari) and now your browser shows 694px)
so exact same bug but now in reverse. Only on Safari Desktop Mac. so not sure if this is again a safari bug or if its a real bug... but it absolutely will break your navigation stack because you are again switching between 2 media queries on the fly based on the scrollbar being there or not.
hawkgs commentedon Jun 19, 2026
I'll reopen this then. I guess we need a more careful analysis of the scrollable containers of A.dev. Won't be surprised if there are more UI glitches that are present if we set the viewport width close to a breakpoint.