main drop-down menus displayed on wrong monitor (negative coordinates)

RESOLVED WONTFIX

Status

--
major
RESOLVED WONTFIX
14 years ago
4 years ago

People

(Reporter: jolyon, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

On a dual monitor setup, the main mozilla menus are displayed on the wrong
monitor if mozilla is runnning on a monitor to the left of the primary display
(where the X coordinate would be negative). It appears the coordinates are being
stored as unsigned values rather than signed, or being rounded up to zero.

Selecting a URL from the URL input bar history similarly is incorrect, however
form elements on actual HTML pages, such as the elements on this page, do appear
on the right screen when selected.


Reproducible: Always
Steps to Reproduce:
1. Set up two monitors, with the RIGHT monitor as primary display
2. Run mozilla on the LEFT (secondary) monitor
3. Access any drop-down menu

Actual Results:  
Drop down menu appears at the left edge of the RIGHT monitor

Expected Results:  
Drop down menu should appear within the mozilla application on the LEFT monitor.
This may have been fixed in bug 135079 some time ago. Please try Mozilla 1.7 RC
3, and mark this duplicate or worksforme if it works

Comment 2

14 years ago
My name is Akshay V. Rao.  I had this same problem except my version of Mozilla
is 1.7.  Just to give the right people the heads up that this problem still exists.

Comment 3

14 years ago

I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1

The same issue still exists.

Though in reverse.  All of my menus are appearing on the left and primary monitor.

Comment 4

14 years ago
I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7)
Gecko/20050414 Firefox/1.0.3 and the problem is exactly at described by the
original poster.

Comment 5

13 years ago
I have my secondary monitor to the right of my primary monitor. Thunderbird and
Firefox menus appear on the left of the primary monitor, at the correct height,
when the programs are running on the primary monitor. This occurs in both the
maximised and normal window sate. The rest of the problem is as the original report.

I am Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8)
Gecko/20050511 Firefox/1.0.4 on Windows XP SP1 Home

Comment 6

13 years ago
The bug is correct but I think the reasoning is wrong.  I have a dual monitor
setup where the primary is on the left and the secondary on the right.  If an
instance of Mozilla/FireFox is in the secondary/right monitor, all of it's menus
open along the right edge of the primary/left monitor.

I believe this behaviour is a result of some logic in the menu rendering
algorithms that is designed to avoid rendering menus off screen (clipping). 
With a single display setup, if a menu to be drawn would clip off screen the
menu is floated to avoid clipping.  You can test this by dragging a browser
window so that half of the file menu button is off the left side of the your
screen.  When you click on that menu button, the menu is floated to the right
slightly so it is not clipped.  In a multi monitor setup, the menus are always
rendered on the primary display regardless of the location browser window.  They
are however rendered at the edges closest to the browser window on the alternate
display which leads me to believe that the algorithm that renders menus is
determining the coordinate space of the desktop based only on the primary
desktop and not enumerating through all available desktops.

An easy way to solve this and to maintain the clipping logic's integrity would
be for the renderer to determine which display the focused control resides on,
take it's coordinates and apply the clipping logic to those.

Comment 7

12 years ago
My situation is when the multiple monitors are configured with second one on top of the primary laptop monitors.  There, I'd say 80% of the lower tier bookmark folders don't open.  A few do, I haven't seen a pattern that appears to make a few work but most not.  To reproduce setup, in the place in windows where you enable an attached monitor, you can drag it to the top to tell windows the wrapping-orientation/direction that is expected.  So, mine was '2'(second) above '1'(primary).  Most probably know about the dragging around of the second monitor, but it was something I just recently learned; so I'm not trying to talk down to the reader.

Comment 8

12 years ago
I run into this problem often. It doesn't matter if my primary monitor is LEFT or RIGHT. Here's how I can re-create the bug:

-Start FireFox with one display active.
-Connect second display (LEFT or RIGHT, doesn't matter)
-Move FireFox window to second display
-Click in address bar to trigger the drop down menu, it will draw on the wrong screen.

Comment 9

10 years ago
Steps to duplicate on OSX, on a laptop:

- Laptop display is primary
- disconnect external monitor, wait for OSX to notice
- launch FF
- reconnect external monitor, wait for OSX to notice
- move FF to external monitor
- open any window-level dropdown

screenshot:

http://www.jslibrary.org/images/temp/FF_monitor_bug.jpg

Comment 10

10 years ago
FYI: 2.0.0.14 exhibits this bug, FF3 doesn't seem to exhibit this bug.
Product: Core → Core Graveyard

Comment 11

10 years ago
I will refresh this here, and start a new bug, because it may have to do with using windows 7.  For the moment, it shall suffice to say that this bug has returned at least as of build Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090314 Minefield/3.2a1pre (.NET CLR 3.5.30729)

Comment 12

10 years ago
I am using today's "Nightly" of Firefox 3.5 (b4) and I am having this issue with the same reproduction steps as above on Windows XP. I did not have the issue until today's nightly.
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.