514891 - right-click context menu only appears on the primary of two monitors

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[superpie]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090905 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090905 Minefield/3.7a1pre

I have two monitors, side-by-side. My left is set as the "primary" in the windows display properties. When I have Firefox on my secondary monitor, on the right side, and I right-click in the middle of a page to bring up the context menu it appears on the wrong (left) monitor very close to the edge as if it were not allowed to enter my secondary monitor's space. It works fine and appears where it should when Firefox is entirely on my primary monitor, though.

Reproducible: Always

Steps to Reproduce:
1. Move Firefox to your secondary monitor
2. Right-click on a web page
Actual Results:  
Context menu appears on the primary monitor

Expected Results:  
Context menu appearing where I right-clicked on the secondary monitor

Comment 1

[Vlado Valastiak [:wladow]]

Confirmed. Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.3a1pre) Gecko/20090905 Minefield/3.7a1pre

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Reporter, is the Firefox window positioned completely on the second screen or is it visible on both screens?

Comment 3

[:Mook]

(Not the reporter)
This only appears to happen when the majority of the top level window is on the secondary screen.  (Note, not the majority of the <tabbrowser>; checked when the sidebar is open.)  When it does occur, it only applies to context menus (i.e. the Test Pilot menu, which is anchored on the item in the status bar, behaves fine) and is not restricted to content (the context menu for the address bar is also broken).

Yes, that does mean this occurs when the window straddles the screen boundary - but only if it's far enough into the secondary display.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090906 Minefield/3.7a1pre

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mook, isn't that visible for you with Firefox 3.5.2 too? I would tend to say it is a dupe of bug 466169.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #4)
> Mook, isn't that visible for you with Firefox 3.5.2 too? I would tend to say it
> is a dupe of bug 466169.

The bug was reported 2008, so, this is not dup of the bug.

This bug should be a regression of bug 445749. I can fix this bug with backing-out the patch of it.

Comment 6

[Sylvain Pasche]

The tooltips popups are also affected, I guess it will be fixed at the same time.

Comment 7

[Timothy Nikkel (:tnikkel)]

Hmm, the changes in bug 445749 were to make the popup behaviour match the comments above openPopupAtScreen here http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/public/nsIPopupBoxObject.idl#146. Specifically, that the coordinates passed to openPopupAtScreen are relative to the current screen. But it seems I forgot about the other consumers, and they send coordinates in absolute screen space.

I think the best way to fix this is to just fully revert bug 445749 and change the meaning of the coordinates passed to openPopupAtScreen, as it seems to be the only place to use screen coordinates that are relative to the current screen. Ctrl+tab is the only real consumer of openPopupAtScreen (a few tests use it, but they should be fine), and also its behaviour was buggy in this regard prior to bug 445749 anyways. Neil, how does that sound to you?

Comment 8

[Dão Gottwald [:dao]]

(In reply to comment #7)
> I think the best way to fix this is to just fully revert bug 445749 and change
> the meaning of the coordinates passed to openPopupAtScreen, as it seems to be
> the only place to use screen coordinates that are relative to the current
> screen. Ctrl+tab is the only real consumer of openPopupAtScreen (a few tests
> use it, but they should be fine), and also its behaviour was buggy in this
> regard prior to bug 445749 anyways.

How exactly was it buggy? Prior to bug 445749, the Ctrl+Tab panel used screen.availLeft, which apparently is /not/ relative to the current screen. Didn't bug 445765 actually fix what bug 445749 was about?

Comment 9

[Timothy Nikkel (:tnikkel)]

(In reply to comment #8)
> (In reply to comment #7)
> > I think the best way to fix this is to just fully revert bug 445749 and change
> > the meaning of the coordinates passed to openPopupAtScreen, as it seems to be
> > the only place to use screen coordinates that are relative to the current
> > screen. Ctrl+tab is the only real consumer of openPopupAtScreen (a few tests
> > use it, but they should be fine), and also its behaviour was buggy in this
> > regard prior to bug 445749 anyways.
> 
> How exactly was it buggy? Prior to bug 445749, the Ctrl+Tab panel used
> screen.availLeft, which apparently is /not/ relative to the current screen.

Sorry, I meant that openPopupAtScreen was buggy (treating coordinates as absolute and not relative to the current screen), not Ctrl+Tab.

> Didn't bug 445765 actually fix what bug 445749 was about?

If we take my proposed solution to this bug (reverting bug 445749), then yes bug 445765 is what fixed bug 445749.

Comment 10

[Dão Gottwald [:dao]]

fixed by backout

(In reply to comment #7)
> change the meaning of the coordinates passed to openPopupAtScreen

filed bug 515028