mui
[material-ui] Take browser zoom into account when calculating scrollbar size
This PR resolves an issue with to how the scrollbar is measured to prevent a horizontal shift that can happen to elements when applying the scroll lock for certain window sizes and zoom levels.
How to reproduce the scrollbar zoom issue? (I'm using Windows 11 and Edge with 100% UI scaling in Windows.)
We can use the mui docs (for example Modal)
- Open the dev tools so that you can easily know the exact window size, and change it to be 1200px wide (it doesn't have to be exact but the problem only occurs for some zoom level and window width combinations)
- Zoom out to 90%
- Trigger a scroll lock, I click the little ⋮ icon at the top of each Demo
- You should see the "Post a comment" icon shift, and also the search bar and following icons in the AppBar
- Without resizing the window change the zoom level to 80%
- Now things act as desired, same for 75%, but it goes wrong for 67%
I have not been able to reproduce the issue for all zoom levels, but for various widths the problem occurs for the following zoom levels: 67%, 80%, 90%, 110%, 175%
- [x] I have followed (at least) the PR section of the contributing guide.
Netlify deploy preview
https://deploy-preview-47408--material-ui.netlify.app/
Bundle size report
| Bundle | Parsed size | Gzip size |
|---|---|---|
| @mui/material | 🔺+340B(+0.07%) | 🔺+131B(+0.09%) |
| @mui/lab | 0B(0.00%) | 0B(0.00%) |
| @mui/system | 0B(0.00%) | 0B(0.00%) |
| @mui/utils | 🔺+340B(+2.65%) | 🔺+117B(+2.32%) |
Generated by :no_entry_sign: dangerJS against 3900765cca993c5550f907ed91cfea3818bd85d9
Ok, I figured since they both resolve issues that occur with the scroll lock that they could go in together.
I split out the padding-right change to https://github.com/mui/material-ui/pull/47420
Here is a screen recording of the problem: https://sendvid.com/ifpkx74b
Thanks for the recording. I don't see any AppBar icons shifting when clicking the ⋮ icon in the demo. I do notice a slight page shift when the scrollbar is hidden, but that seems like expected behavior and should be fine.
The problem is caused by window.innerWidth and window.document.documentElement.clientWidth both being integers, when the actual widths might not be. window.document.documentElement.getBoundingRects().width is a float but there is no equivalent for just window.
Here is a table I made of the actual devicePixelRatio values (MDN has a helpful demo)
| Zoom | devicePixelRation (100% UI Scaling) | devicePixelRatio (125% UI Scaling) |
|---|---|---|
| 125% | 1.25 | 1.5625 |
| 110% | 1.100000023841858 | 1.375 |
| 100% | 1 | 1.25 |
| 90% | 0.8999999761581421 | 1.125 |
| 80% | 0.800000011920929 | 1 |
| 75% | 0.75 | 0.9375 |
| 67% | 0.6666666865348816 | 0.8333333730697632 |
As you can see the actual devicePixelRatio is a float, which is inexact, and this means that the current way of calculating the scrollbar width is sometimes slightly off. This leads to the page shifting, something the scroll lock is meant to counter.
Other than the comment stating the obvious that I did not add test cases for different values of devicePixelRatio everything generated by Copilot has been complete slop. And even that comment isn't helpful. The only type of test that would add value there would be a playwright test that compared screenshots, but given how isolated this code is it's not going to be broken by changes to anything other than changes to itself. The extra duration added to run such a test is a much higher cost than any benefit it would bring.
I have now spent about 1 hour of my time refuting the slop generated by Copilot. It has been 100% negative productivity
@Zache In the screen-recording below at https://mui.com/material-ui/react-modal/, I am at 1200px wide and at 90% browser zoom level. I don't see any noticeable shift in icons:
https://github.com/user-attachments/assets/31b82552-0e2b-47de-b0d2-94fa80faa44c
@ZeeshanTamboli I'm not sure that I understand you. When you write: "I don't see any noticeable shift" does that mean that you don't notice the horizontal shift of:
- The icons in the toolbar containing the menu you open?
- The icons in the AppBar?
- The do it sponsor logo?
Because I very much notice it and so do colleagues which I showed your screen recording. Perhaps when you write "don't see any noticeable" you mean don't think the shift is significant enough to warrant fixing? If that is the case, then I must say that I disagree.
I think that the horizontal shift that can happen when zoomed in is both noticeable and significant, even if it is very small. If such a shift would be expected then I don't understand why MUI tries to counteract it when applying the scroll lock. The application where we use MUI is very rich and contains a lot of content. For accessibility reasons we have to keep that content at a certain size but many of our users habitually work zoomed out (especially those who work from laptops), and we would like them to have the same crisp and professional experience as every other user.
@ZeeshanTamboli I'm not sure that I understand you. When you write: "I don't see any noticeable shift" does that mean that you don't notice the horizontal shift of:
- The icons in the toolbar containing the menu you open?
I don't notice shift in this.
- The icons in the AppBar?
Yes, I notice a slight shift there if I look carefully.
- The do it sponsor logo?
Not here.
Because I very much notice it and so do colleagues which I showed your screen recording. Perhaps when you write "don't see any noticeable" you mean don't think the shift is significant enough to warrant fixing? If that is the case, then I must say that I disagree.
Yes, I thought is it that significant and worth it?
I think that the horizontal shift that can happen when zoomed in is both noticeable and significant, even if it is very small. If such a shift would be expected then I don't understand why MUI tries to counteract it when applying the scroll lock.
I agree with you.