react-remove-scroll is shifting my fixed header every time a radix select is opened

[jtabone16]

I've seen #1340 and #1100 and updating radix select to 1.0.0 doesn't fix the issue. Seeing this on Mac and Windows on all browsers.

Note that overflow: hidden !important; and margin-right: 15px !important; on the body via react-remove-scroll is causing the issue

[benoitgrelard]

Hi @jtabone16,

This is due to how react-remove-scroll handles the scrollbar removal technique.
When you have fixed elements, you have do add some additional classes to those elements to avoid them shifting.

We have to do it to our sidenav in our own docs for the same reason:

https://github.com/radix-ui/website/blob/8c5a605f07879131e0f7a7e3fd777bb3604672d1/pages/docs/design-system/overview/%5Bslug%5D.tsx#L34-L41

[jtabone16]

Hmm now it's shifting on the left side

[benoitgrelard]

It depends what is your fixed element:

• Is it a fixed element positioned on the right? Then use RemoveScroll.classNames.zeroRight
• Is it a fixed element that is full width? Then use RemoveScroll.classNames.fullWidth

[jtabone16]

it is full width and using that class doesn't fix the issue :/ it still shifts on the right side

[benoitgrelard]

We use it on our docs and it definitely works so perhaps there's something wrong in how yours is setup?
You can take a look at our implementation/styles here: https://github.com/radix-ui/website/blob/8c5a605f07879131e0f7a7e3fd777bb3604672d1/components/Header.tsx#L31

You can see the fixed header on any component docs pages: https://www.radix-ui.com/docs/primitives/components/dropdown-menu

[seanssel]

I still notice quite a bit of layout shift on your docs pages. Easier to see in the video in fullscreen, but you can see a bunch of stuff slightly shifting.

radix-shift.mov

[58bits]

Hi All - I've just bumped into this as well, and have also noticed that either react-remove-scroll or radix adds the following css var to the body element when the select component is triggered...

body {
	--removed-body-scroll-bar-size: 17px
}

Since that var is available, I'm assuming (safely?) that it could be used to create a custom class with additional padding added to fixed elements as required in order to prevent the shift?

In our case, we import our Radix controls via a uikit in a monorepo, and so would prefer not to import the react-remove-scroll component directly into the application.

And so instead we created a utility class that we can apply to fixed elements - like a fixed header, as follows:

.fix-scroll-layout-shift-right {
  padding-right: var(--removed-body-scroll-bar-size);
}

.fix-scroll-layout-shift-left {
  padding-left: var(--removed-body-scroll-bar-size);
}

Are we miles out? Or does this look okay?

[hedysnike]

how do i keep the radix from resizing thou

[firxworx]

@benoitgrelard this is obviously a recurring annoyance...

Throwing out there $0.02:

I think that Radix should in-house the scrollbar offset vs. relying on a third-party deps for something like this, and then provide devs with options for greater control.

---

In my case I set scrollbars to always appear on the body so there is no "jump" when navigating between pages (e.g. one long enough to have a scroll vs. one that doesn't have a scroll). This is especially noticeable for PC users with a fat scrollbar. It neatly solves jank with modals etc. as well (except when using certain libs... including radix)

This simple trick also solves jank caused by modals hiding scrollbars when a layout's full-width backgrounds don't "stretch" to under the scrollbar (e.g. nav, body, footer different colours) (when this trick is done with a supporting modal implementation that can be configured to not hide the scrollbar and just lock the scroll so there is no jank / jump).

Following through chains of issues and discussions is a bit of a pain and from Google this comes up again and again
e.g. #1100

IMHO this is a sign that more flexible support is a requirement to be embraced :)

As a headless library meant to provide devs with drop-in a11y improvements to their project, I think it is in line with my understanding of the project goals, and enables radix to be better integrated with apps across Dialog, menus, etc.

I suppose the same sentiment for first-class support includes for multiple/stacked modals and auto-triggered modals (such as session timeout warnings, or very "desktoppy" UX enterprise/business apps that might pop over with connectivity interruptions or important real-time business interruptions -- where there can be >1 even from totally different causes).

I love radix and would love to be able to use it for everything!

[ThePiyushAggarwal]

Can someone please help me out? Why does Radix UI disables the scrolling when the dropdown is open?

[firxworx]

@ThePiyushAggarwal this threw me off too when I first started using radix-ui.

Answer: radix-ui treats the default behaviour of a dropdown menu as a "modal".

Good news: you can disable this behaivour.

Check out the docs w/ jumplink to the right section and look for modal in the table of available props:
https://www.radix-ui.com/primitives/docs/components/dropdown-menu#root

The docs might not be clear especially for those who are not familiar with the concept of modals in general.
If that's you check out https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ (among other references). Generally this means focus lock, and the page underneath shouldn't be scrollable or interactive (in a modal dialog implementation you often see an overlay used that makes this more intuitive).

Personally I don't think this default aligns with how a dropdown is generally understood or implemented in the majority of UI's I come across.

Either way, you have your answer my friend.

Unfortunately per my comment above the use of third party libraries to achieve "modal" is pretty inflexible and obtrusive w/ limited configuration options. Even radix can't escape it and there's code to try to workaround in places re the docs! For example at the above docs link, toggle the dropdown menu in the preview and notice how the topmost horizontal nav "janks" and layout shifts.

[ThePiyushAggarwal]

Thanks for this! I could solve the issue.

[sannajammeh]

The obvious problem here is that this conflicts with now stable API scrollbar-gutter: stable.

This is the culprit. Two problems here:

1. it's added as a general style tag on thehead so overriding becomes difficult
2. it's using !important completely removing our way to override.

Fix when using scrollbar-gutter:

Postcss nested or Sass

html {
   scrollbar-gutter: stable;
}
/* html tag is required here to provide higher specificity */
html {
  @supports (scrollbar-gutter: stable) {
    body {
      margin: 0 !important;
    }
  }
}

[brianlovin]

This fix worked for us when using scrollbar-gutter: stable — thanks!

[bepyan]

In my case, simply removing the width: 100% from the body works perfectly fine.
Maybe use 100vw instead.

html,
body {
  width: 100%; /* <<< remove it */
  height: 100%;
}