[Popper] Position shift when the scroll is blocked

[cherniavskii]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/loving-fast-7scfjf?file=/demo.tsx

Steps:

1. Open the Popper
2. Open the Select

Current behavior 😯

When Popper has *-end placement, its position shifts when the scroll is blocked:

Screen.Recording.2023-05-08.at.12.09.01.mov

Expected behavior 🤔

Popper's position should not shift (it doesn't when the placement is changed to *-start):

Screen.Recording.2023-05-08.at.12.09.14.mov

Context 🔦

We noticed this in MUI X mui/mui-x#6619 (comment)

The issue can be solved with the mui-fixed className applied to the Popper:

<Popper className="mui-fixed" />

Demo: https://codesandbox.io/s/hidden-breeze-92jzki?file=/demo.tsx

But we can make this fix unnecessary by applying mui-fixed automatically when the placement is set to *-end.

Your environment 🌎

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[michaldudak]

Thanks for reporting this. I'll look into it.

[michaldudak]

The logic would have to be more complicated than just adding mui-fixed class when placement is *-end, especially if you consider RTL rendering. Also, the auto placement caused some issues when I was testing it, so I think leaving it as is, with the recommendation in https://mui.com/material-ui/getting-started/faq/#why-do-the-fixed-positioned-elements-move-when-a-modal-is-opened won't accidentally break anything.

[cherniavskii]

I think leaving it as is, with the recommendation in mui.com/material-ui/getting-started/faq/#why-do-the-fixed-positioned-elements-move-when-a-modal-is-opened won't accidentally break anything.

Yeah, my main concern here is the fix is not obvious at all 🙂

Also, the auto placement caused some issues when I was testing it

Out of curiosity, what issues did it cause?

[oliviertassinari]

The issue can be solved with the mui-fixed className applied to the Popper:

This sounds to me like the correct way to fix this. I'm not aware of anything else needed. But yes, maybe the Popper should be smart about it and be able to reposition itself automatically, so a bug?

I think that there could be a docs issue as well, maybe we would want to remove as much as possible from https://mui.com/material-ui/react-modal/ and link back to https://mui.com/base/react-modal/#overflow-layout-shift starts to explain the solution. A demo there would be nice as well.

[michaldudak]

@cherniavskii, the new Popup from Base UI does not suffer from this issue (unless I missed something): https://codesandbox.io/s/friendly-noyce-dd3r2d?file=/demo.tsx
Could you please verify?

[cherniavskii]

@michaldudak Yes, I confirm that the Popup component does not suffer from this issue: https://codesandbox.io/s/bold-lamarr-zvh75k?file=/demo.tsx
(I had to update the import statement to make the demo work)

[michaldudak]

Would using the Popup instead of Popper be a good workaround in your use case? We're planning to deprecate the Popper in the future, so I'm not keen on investing time to fix its bugs.

[cherniavskii]

We're currently using the className="mui-fixed" workaround, but in the future, we can migrate to the Popup as they seem to be easily replaceable 👍🏻
Feel free to close this issue 🙂