1244129 - [Mac OSX] [HiDPI 4K] Tooltips, context menus, and plugin drop down menus are displaying on the secondary monitor when they fall within the right half of the primary monitor.

Status: RESOLVED DUPLICATE of bug 1240533

(Core :: Widget: Cocoa, defect)

Description

[filchermcurr]

Attachment: Exact Windows Size and Position.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160114030246

Steps to reproduce:

1.) Configure monitors so that the taskbar (main monitor) is on the left and the second display is on the right.
2.) Move the Firefox window so that it occupies the right half of the primary monitor.
3.) Right-click, hover over tabs, click the hamburger menu, or click a plugin (like LastPass) that opens a popup menu.


Actual results:

The result is that the context menu or tooltip will appear on the leftmost edge of the secondary monitor. It will be in the correct position along the Y-axis but on the wrong monitor.

Plugin dropdowns and the hamburger menu don't appear at all.


Expected results:

The expected result is for the tooltip or context menu to appear directly under the cursor. Failing that, it should appear on the same monitor as the Firefox window.

Additional information that may or may not be helpful:
 * Both monitors are "4K" so could involve DPI shenanigans.
 * I ruled out operating system and Firefox profile issues by installing a fresh copy of OS X 10.11.3 on a separate drive and starting Firefox Nightly without restoring a profile. (I did eventually install a couple of extensions for convenience but I confirmed the issue BEFORE installing them.)
  * The issue only appears when Firefox is in the right half of the left monitor. 
  * The bug didn't start happening until the January 14th builds.
  * Disabling hardware acceleration doesn't help, nor has any combination of setting changes that I could find.
  * I'm using the NVidia web drivers and not the built-in OS X drivers.
  * Works correctly on Nightly builds from January 1st up to January 13th.

The screenshot shows the display arrangement and the exact size and position of the Firefox window.

Comment 1

[filchermcurr]

Oh, I should clarify: The issue only occurs within the area that Firefox occupies in the screenshot. If you make the window bigger (maximize it, for example) everything will work normally on the left-hand side but continue to fail on the right-hand side. So exact window placement isn't necessary, that's just demonstrating the affected area.

Comment 2

[filchermcurr]

Oh, huh. It's actually only the upper right. Once you get about halfway down the context menu will display correctly.

Comment 3

[filchermcurr]

With all the version switching I was doing to test, I didn't even notice we were in 47 now. The bug is still relevant on the latest (as of 1-29-16) version of Nightly, just in case the user agent in the original post or my incompetence in version selection throws you off.

I'm clearly very new to this! Sorry for the million annoying corrections.

Comment 4

[filchermcurr]

Just tested this on my 2012 rMBP with an iPad and Duet Display. I guess the position of the Firefox window varies from system to system. On the laptop the hamburger menu didn't stop responding until the Firefox window was more centered on the main display, not pushed all the way to the right like on the original machine.

So I guess the updated steps to reproduce would include moving the window around and trying the hamburger menu / right-clicking after small movements. Not very helpful or scientific, I'm afraid.

Comment 5

[Brian Mastenbrook]

This is definitely happening for me as well between my primary external monitor (a 4K display arranged to the left) and my secondary internal display (a 2013 13" Retina MacBook Pro). As the originator of the issue notes, it only occurs when the popup would be in the top right corner of the external display.

Comment 6

[Brian Mastenbrook]

Using mozregression, I narrowed the regression to this set of changes: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=98756a36223c1a2b51cd0368736b728429038caf&tochange=a9f9b36c1a2eec7626e6b749e46ab0a8bf3323e2

Comment 7

[Loic]

Bug 890156 is for Windows 8.1/10, so I guess the culprit is the change made in the other bug 1239007 about Widget Cocoa.

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to Loic from comment #7)
> Bug 890156 is for Windows 8.1/10, so I guess the culprit is the change made
> in the other bug 1239007 about Widget Cocoa.

Actually, the problem is among the bug 890156 patches; although that bug was about a Windows feature, some of the changes are in cross-platform code.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking, this is one of the many regressions from bug 890156. 

[e-mail] and Brian, thanks very much for your detailed bug reports!

Comment 10

[Jonathan Kew [:jfkthame]]

I believe this should have been fixed by bug 1240533. Could you confirm whether you still see the problem with today's Nightly? Thanks.

Comment 11

[filchermcurr]

(In reply to Jonathan Kew (:jfkthame) from comment #10)
> I believe this should have been fixed by bug 1240533. Could you confirm
> whether you still see the problem with today's Nightly? Thanks.

Looks fixed here!

Comment 12

[Brian Mastenbrook]

(In reply to filchermcurr from comment #11)
> Looks fixed here!

Also fixed for me.

Comment 13

[Jonathan Kew [:jfkthame]]

OK, thanks - that confirms this as a duplicate of bug 1240533.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking in bug 1240533, untracking here.