layout.css.devPixelsPerPx set to something other than the OS DPI trashes context menus
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
People
(Reporter: streetwolf52, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
18.80 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170226123004 Steps to reproduce: I'll give STR based on my setup. 1. Make the OS default DPI 125% 2. Set layout.css.devPixelsPerPx to 1.24 or anything else for that matter. 3. Display a context menu either by right clicking or a menu from the menu bar. Actual results: As you move the pointer through the options on the menu extra lines appear. Expected results: No extra lines should appear. It appears that the only setting that will not produce extra lines is either setting layout.css.devPixelsPerPx = -1 or 1.25 which in both cases is the default OS dpi.
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Updated•7 years ago
|
Comment 1•7 years ago
|
||
Regression due to landing of Bug 1254020
Updated•7 years ago
|
Comment 2•7 years ago
|
||
Bug 1254020 only exposed the hidden problem. The bug should happen on multiple-monitor systems even before bug 1254020 lands.
Comment 3•7 years ago
|
||
Too late for 51 and we've built 52 RC. Mark 51 won't fix.
Reporter | ||
Comment 4•7 years ago
|
||
I want to point out a problem that is caused by this bug. My OS dpi is 120. I set layout.css.devPixelsPerPx to 1. I do this so Fx is using 96 dpi. When I go above 96 graphics become blurry both in the Chrome and the Content. To overcome the small size that 96 dpi incurs I use a new WebExtensions add-on called Zoom Page WE to make the Content text bigger along with setting Fx's zoom mode to Text Zoom Only. Graphics don't increase in size therefore don't get blurry. Fx at 96 DPI makes menu text and icons small. I am able to overcome this by using some css code below. However, once I use this code I get the extra lines in the menus. @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); @namespace html url("http://www.w3.org/1999/xhtml"); @namespace svg url("http://www.w3.org/2000/svg"); * :not(.toolbarbutton-badge ) { font-family: 'segoe ui' !important; font-size: 15px !important; }
Reporter | ||
Comment 5•7 years ago
|
||
Just wondering if this will be on somebody's To Do list soon?
Comment 6•7 years ago
|
||
Too late for firefox 52, mass-wontfix.
Comment 7•7 years ago
|
||
Jonathan, emk, jaws? do you have any other ideas here? Anyone who could work on this issue? Is this just an edge case that is going to stay in backlog for a bit?
Comment 8•7 years ago
|
||
I think this is caused by rounding errors when nsNativeThemWin calculates Windows Theme parts size. On Creators Update, OpenThemeDataForDpi may improve the situation.
Comment 9•7 years ago
|
||
Yes, this may well be a rounding-related issue when we have a non-integer device pixel scale in effect. Or an antialiasing-related issue: it kinda looks like the edges of the blue highlighting get antialiased (because with the scaling, it doesn't fall exactly on device pixel boundaries, I assume), but then when we erase it, we don't account for the partially-covered pixels that were painted outside the strict edges of the rect. I don't expect to have time to dig into this in the near future, I'm afraid. If someone else does, great; otherwise I suspect it's "an edge case that is going to stay in backlog for a bit".
Comment 10•7 years ago
|
||
This doesn't appear to be a front-end issue, so dropping needinfo for myself as a I think jfkthame and emk have answered this better than I could.
Reporter | ||
Comment 11•7 years ago
|
||
Would someone please confirm this and mark it as such? More importantly a fix would be appreciated. Thanks.
Updated•7 years ago
|
Reporter | ||
Comment 12•7 years ago
|
||
Why a 'wontfix'? Unless you plan to get rid of 'layout.css.devPixelsPerPx' this is a real problem.
Reporter | ||
Comment 13•7 years ago
|
||
How about fixing this problem on Fx58?
Reporter | ||
Comment 14•6 years ago
|
||
Is anyone going to look into this problem? It still exists in Fx63 Nightly.
Reporter | ||
Comment 15•6 years ago
|
||
Looking forward for this to be fixed.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 16•4 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Same problem started to appear in Nightly in the past few days. Extra lines were not appearing for the longest time until now. I am now running at 3840x2160 (4K). Any value above the default results in the extra lines. My default OS DPI is 200%.
Reporter | ||
Comment 17•3 years ago
|
||
It appears that the 'extra' lines are the leftover pixels from the hover color when scrolling through a menu. The fix might be just a CSS change to the hover height when Layout.css.devPixelsPerPx is not set to the default.
Reporter | ||
Comment 18•3 years ago
|
||
Really looking forward for a fix. Specifying a devPixelsPerPx of 2.2 would improve readability on my large 4K monitor without the leftover line attributed to the hover color. I would at least welcome a snippet of CSS code that might alleviate this problem until a proper fix if found.
Reporter | ||
Comment 19•3 years ago
|
||
FWIW...
I added the following snippet of css code to userChrome.css and the 'phantom lines' are no longer being produced at higher than normal DPIs:
menuitem:hover, menu:hover, menu[open="true"], menuitem[_moz-menuactive="true"] {
box-shadow: 0 1px 4px rgba(0, 0, 0, .05) !important;
}
Perhaps this might help you in fixing the problem officially.
Reporter | ||
Comment 20•3 years ago
|
||
Can this be at least confirmed and perhaps assigned to someone if your resources allow.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•