1305278 - Popup menus appear on wrong screen if layout.css.devPixelsPerPx is 1

Status: RESOLVED FIXED

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

Description

[Ray Satiro]

Attachment: Capture.PNG

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20100101

Steps to reproduce:

Build ID 	20160924030427
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

Windows 7 x64 SP1 with two displays. #1 - 1920x1080 and the desktop is extended to the right with #2 - 1024x768. See attached screenshot. Windows display setting is enlarged at 125%.

Maximize Firefox in display #1, set layout.css.devPixelsPerPx to 1 and right-click in the right-most quarter of Firefox. (It's not reproducible in about:config for some reason, open an actual webpage)


Actual results:

The popups appear on display #2.

I used mozregression to bisect it:
 7:47.61 INFO: Last good revision: 1ea96bf70664dbac2584881fcf39408733278e46
 7:47.61 INFO: First bad revision: 4eb5775fd334887121a7a779a27e6727acdcb25f
 7:47.61 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ea96bf70664dbac2584881fcf39408733278e46&tochange=4eb5775fd334887121a7a779a27e6727acdcb25f
 7:48.15 INFO: Looks like the following bug has the changes which introduced the regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1288760



Expected results:

The popups should appear on display #1 where I am interacting Firefox.

Comment 1

[Ray Satiro]

Attachment: Popups wrong location (animated)

Comment 2

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

New regression in Fx50.

Comment 3

[Marcia Knous [:marcia]]

Tracking 52+ for this new regression.

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to Ritu Kothari (:ritu) from comment #2)
> New regression in Fx50.

If the regression range in comment 0 is accurate, Fx50 should be unaffected; those patches landed after the merge and so are only on Fx51.

Moreover, the patches indicated in comment 0 were recently backed out (see bug 1300421), so I expect this should be fixed in current Nightly (and approved for uplift to Aurora). Ray, can you confirm whether this is fixed for you in Nightly? Thanks.

Comment 5

[Ray Satiro]

(In reply to Jonathan Kew (:jfkthame) from comment #4)
> Ray, can you confirm whether this is fixed for you in Nightly? Thanks.

Nightly yes:
20161003030438
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

Aurora not yet:
20161003004005
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Ray Satiro from comment #5)
> Aurora not yet:
> 20161003004005
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0

That makes sense, as the backout only landed on Aurora late on Oct 3rd, so the earliest it could have gone into a build would be 2016-10-04.

Could you re-test with current Aurora and confirm whether the problem still occurs there? Thanks.

Comment 7

[Ray Satiro]

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> Could you re-test with current Aurora and confirm whether the problem still
> occurs there? Thanks.

Tested firefox-51.0a2.en-US.win32 11-Oct-2016 0944, looks like you solved it. Thanks!

Comment 8

[Jonathan Kew [:jfkthame]]

OK, thanks for testing; I'll mark this as being fixed (by the backout in bug 1300421).

Comment 9

[Gerry Chang [:gchang]]

Un-track for 51 as fixed in 51.