Skip to content

Scroll root on body causes 8 px gutter flicker (safari) #69036

Description

@zurie

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.
Image
Image

Enter the URL of the topic with the problem

https://angular.dev

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

  1. added this to the needsTriage milestone on Jun 1, 2026
  2. added this to the needsTriage milestone on Jun 1, 2026
  3. added
    area: docsRelated to the documentation
    area: docs-infraAngular.dev application and infrastructure
    open for contributionsAn issue that is suitable for a community contributor (based on its complexity/scope).
    and removed
    area: coreIssues related to the framework runtime
    area: docsRelated to the documentation
    on Jun 1, 2026
  4. zurie commented on Jun 5, 2026

    @zurie
    Author

    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?

  5. hawkgs commented on Jun 11, 2026

    @hawkgs
    Member

    @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.

  6. zurie commented on Jun 11, 2026

    @zurie
    Author

    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.

  7. hawkgs commented on Jun 12, 2026

    @hawkgs
    Member

    Thanks for the provided information. I thought it's a pure classic vs. overlay scrollbar issue.

  8. added a commit that references this issue on Jun 12, 2026
    db677a4
  9. added a commit that references this issue on Jun 12, 2026
    02c1652
  10. zurie commented on Jun 18, 2026

    @zurie
    Author

    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.

  11. hawkgs commented on Jun 19, 2026

    @hawkgs
    Member

    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.

  12. reopened this on Jun 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: docs-infraAngular.dev application and infrastructureopen for contributionsAn issue that is suitable for a community contributor (based on its complexity/scope).

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions