1342821 - layout.css.devPixelsPerPx set to something other than the OS DPI trashes context menus

Status: NEW

(Core :: Widget: Win32, defect, P3)

Description

[Gary [:streetwolf52]]

Attachment: Extra lines after moving the pointer through the options.

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.

Comment 1

[Alice0775 White]

Regression due to landing of Bug 1254020

Comment 2

[Masatoshi Kimura [:emk]]

Bug 1254020 only exposed the hidden problem. The bug should happen on multiple-monitor systems even before bug 1254020 lands.

Comment 3

[Gerry Chang [:gchang]]

Too late for 51 and we've built 52 RC. Mark 51 won't fix.

Comment 4

[Gary [:streetwolf52]]

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; }

Comment 5

[Gary [:streetwolf52]]

Just wondering if this will be on somebody's To Do list soon?

Comment 6

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 7

[Liz Henry (:lizzard)]

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

[Masatoshi Kimura [:emk]]

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

[Jonathan Kew [:jfkthame]]

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

[Jared Wein [:jaws] (please needinfo? me)]

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.

Comment 11

[Gary [:streetwolf52]]

Would someone please confirm this and mark it as such?  More importantly a fix would be appreciated.  

Thanks.

Comment 12

[Gary [:streetwolf52]]

Why a 'wontfix'?  Unless you plan to get rid of 'layout.css.devPixelsPerPx' this is a real problem.

Comment 13

[Gary [:streetwolf52]]

How about fixing this problem on Fx58?

Comment 14

[Gary [:streetwolf52]]

Is anyone going to look into this problem?  It still exists in Fx63 Nightly.

Comment 15

[Gary [:streetwolf52]]

Looking forward for this to be fixed.

Comment 16

[Gary [:streetwolf52]]

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%.

Comment 17

[Gary [:streetwolf52]]

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.

Comment 18

[Gary [:streetwolf52]]

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.

Comment 19

[Gary [:streetwolf52]]

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.

Comment 20

[Gary [:streetwolf52]]

Can this be at least confirmed and perhaps assigned to someone if your resources allow.