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

NEW
Unassigned

Status

()

Firefox
Menus
11 months ago
3 months ago

People

(Reporter: streetwolf, Unassigned)

Tracking

({regression})

47 Branch
x86_64
Windows 10
regression
Points:
---

Firefox Tracking Flags

(firefox51 wontfix, firefox52 wontfix, firefox53 wontfix, firefox54 fix-optional, firefox55 wontfix, firefox56 wontfix, firefox57 wontfix)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 months ago
Created attachment 8841385 [details]
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.
(Reporter)

Updated

11 months ago
Component: Untriaged → Menus
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
(Reporter)

Updated

11 months ago
Summary: layout.css.devPixelsPerPx set to something other than the OS default DPI trashes context menus → layout.css.devPixelsPerPx set to something other than the OS DPI trashes context menus

Comment 1

11 months ago
Regression due to landing of Bug 1254020
Blocks: 1254020
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: 54 Branch → 47 Branch

Updated

11 months ago
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected

Comment 2

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

Comment 3

11 months ago
Too late for 51 and we've built 52 RC. Mark 51 won't fix.
status-firefox51: affected → wontfix
(Reporter)

Comment 4

11 months 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

11 months ago
Just wondering if this will be on somebody's To Do list soon?
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
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?
status-firefox53: affected → wontfix
status-firefox54: affected → fix-optional
status-firefox55: --- → affected
Flags: needinfo?(jfkthame)
Flags: needinfo?(jaws)
Flags: needinfo?(VYV03354)
I think this is caused by rounding errors when nsNativeThemWin calculates Windows Theme parts size.

On Creators Update, OpenThemeDataForDpi may improve the situation.
Flags: needinfo?(VYV03354)
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".
Flags: needinfo?(jfkthame)
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.
Flags: needinfo?(jaws)
(Reporter)

Comment 11

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

Thanks.
status-firefox55: affected → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → wontfix
(Reporter)

Comment 12

4 months ago
Why a 'wontfix'?  Unless you plan to get rid of 'layout.css.devPixelsPerPx' this is a real problem.
(Reporter)

Comment 13

3 months ago
How about fixing this problem on Fx58?
You need to log in before you can comment on or make changes to this bug.