Closed Bug 1251624 Opened 4 years ago Closed 4 years ago

The menu appears on the second monitor with Nightly


(Core :: Widget: Win32, defect)

47 Branch
Windows 10
Not set



Tracking Status
firefox47 --- fixed


(Reporter: sime.vidas, Assigned: jfkthame)



(3 files)

Attached image Capture.PNG
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

On Windows 10, when Firefox Nightly (currently 47) is maximized on my primary monitor and I press the main menu button (hamburger icon in the upper right)…

Actual results:

…the menu shows up on my secondary montiro. I’ve made a video of this issue here: (first window is Firefox, second window is Firefox Nightly).

I’m attaching a screenshot of my current multi-monitor settings on Windows 10.

Expected results:

The menu should appear on my primary monitor (inside the Firefox window).
Component: Untriaged → Widget: Win32
Product: Firefox → Core
Summary: The menu appears on the second monitor → The menu appears on the second monitor with Nightly
Jonathan, as you  worked on some patches about per-monitor DPI recently, might it be related?
Flags: needinfo?(jfkthame)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
This is probably a duplicate of bug 1240533. If so, a fix landed recently. Please update to the latest Nightly ("Build ID 20160210153822" suggests it hasn't been updated for a couple of weeks) and see if it still occurs.
Flags: needinfo?(jfkthame) → needinfo?(sime.vidas)
I’ve found the culprit. I use a custom layout.css.devPixelsPerPx value of 1.35 for my Firefoxes. After resetting the value, the issue disappears.

My Nightly’s build ID is 20160226030256, which should be up to date. It’s just that I always report bugs from Stable, hence the older ID. Is there a way I can check if that bug fix has landed in my version?
Flags: needinfo?(sime.vidas)
20160226030256 includes the fix from bug 1240533 (landed 2016-02-22). So apparently there's still a remaining issue if you set a custom devPixelsPerPx value, although for the default setting it should now be fixed.

I have a guess as to what may be going wrong here... will test and follow up shortly.
OK, I was able to reproduce and confirm the problem here. (Though we should note that custom devPixelsPerPx isn't really a supported thing, so a few glitches are likely.)

Anyway, this is simple to fix. The problem is that WinUtils::MonitorFromRect is given a rect in desktop pixel units (not CSS px), so it should NOT make use of the devPixelsPerPx value when converting to device pixels; that's what causes it to map some click locations to the wrong monitor, so that we then pop up the menu in the wrong place. Patch coming....

Meanwhile, I observed a second problem when using a custom devPixelsPerPx value, too: desktop notification windows (e.g. from the demo are incorrectly positioned. This is basically the opposite problem: in nsScreenWin::GetDefaultCSSScaleFactor, we fail to respect the devPixelsPerPx setting, and that's a problem because the front-end JS code that manages the notification window goes through CSS-px APIs. In this case we do need to include a check for a custom scaling factor to get the correct behavior. So let's fix that at the same time.
Ever confirmed: true
Assignee: nobody → jfkthame
Try build including the two patches above:
Attachment #8724420 - Flags: review?(VYV03354) → review+
Attachment #8724421 - Flags: review?(VYV03354) → review+
Bug 1251624 - patch 1 - The desktop to device scaling in WinUtils::MonitorFromRect should not depend on custom CSS pixel scaling (devPixelsPerPx setting). r=emk
Bug 1251624 - patch 2 - Check for scaling override (devPixelsPerPx setting) in nsScreenWin::GetDefaultCSSScaleFactor, for proper window positioning when a custom scale factor is used. r=emk
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Looks good now. Thanks for fixing this, Jonathan ^_^
You need to log in before you can comment on or make changes to this bug.