Firefox v96.0.3 (64-bit) on Windows 10 Reports Incorrect JavaScript screen.width Values
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
People
(Reporter: techrd, Unassigned)
Details
(Whiteboard: [win:sizing])
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
Steps to reproduce:
Ran Firefox on Windows 10 at each Windows 10 Display Scaling level (100% - 350%). For each Windows 10 Display Scaling level, recorded the value of JavaScript screen.width for each Firefox zoom level from 30% - 300%.
UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Actual results:
Certain combinations of Windows 10 Display Scaling levels and Firefox zoom levels produced duplicate JavaScript screen.width values.
The attached PNG file identifies these duplicated values with a red border. The duplicated values within each red border are highlighted in yellow.
Expected results:
The expected result was that the JavaScript screen.width values for each combination of Windows 10 Display Scaling level and Firefox zoom level would be unique .
| Reporter | ||
Comment 1•4 years ago
|
||
ADDITIONAL INFORMATION:
The attached PNG file shows the results with Firefox MAXIMIZED (top data) and WINDOWED (bottom data). This was done to test whether or not the JavaScript screen.width values were different when Firefox was MAXIMIZED and WINDOWED. The results were identical, which was expected.
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•4 years ago
|
||
Thank you for the detailed chart!
Comment 4•4 years ago
|
||
I think this happens because the way we implement these zooms in Firefox is by changing the css to dev pixel ratio. A css pixel is 60 app units (an internal Firefox unit). The way we change the css to dev pixel ratio is by changing the number of app units per dev pixel. For example, if 18 app units per dev pixel then we get an effective zoom of 60/18 = 3.33333. If 17 app units then 60/17 = 3.529. So at these high zoom values we don't have enough "precision" to represent zooms that are just 10% apart. Changing this would be a very deep change to a fundamental part of our rendering engine, so it's not likely to happen unless there is some strong driving reason.
| Reporter | ||
Comment 5•4 years ago
|
||
Thanks, Timothy, for the explanation. I suspected it was a math precision error, so your explanation clears up the cause of the problem for me.
Updated•3 years ago
|
Description
•