It's something called "zoom for DSF" on MacOS, which leads to inaccurate value reporting:
browser
value
Chrome 119.0.6045.107 (Headless/Karma) on Windows 11
1
Chrome 119.0.6045.123 on Mac (MBP M1, MacOS 14.0)
0.5
Webkit Nightly
0
Firefox Nightly
0
So while I do still think that screen DPI is partly to blame for Chrome returning 0.5, it seems that setting scrollLeft to 1 when in rtl mode and receiving anything other than 0 is a bug.
✅ Checklist
General
[x] I have included a change request file using $ yarn change
[ ] I have added tests for my changes.
[x] I have tested my changes.
[ ] I have updated the project documentation to reflect my changes.
[x] I have read the CONTRIBUTING documentation and followed the standards for this project.
Pull Request
📖 Description
Changes the
invertedGetRtlScrollConverter returns correct value
test to pass when any value < 0 is returned.🎫 Issues
This PR reverts #6857.
👩💻 Reviewer Notes
The behavior seems to be related to this Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1324251
It's something called "zoom for DSF" on MacOS, which leads to inaccurate value reporting:
1
0.5
0
0
So while I do still think that screen DPI is partly to blame for Chrome returning
0.5
, it seems that settingscrollLeft
to1
when in rtl mode and receiving anything other than0
is a bug.✅ Checklist
General
$ yarn change