Last Comment Bug 245418 - (ContextMenuScreen) menus and contextual menus open on wrong screen when using two/dual/multiple screens/monitors/displays
(ContextMenuScreen)
: menus and contextual menus open on wrong screen when using two/dual/multiple ...
Status: RESOLVED FIXED
OSX issues are bug 314279
: fixed1.8, polish
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All Windows XP
: -- normal with 10 votes (vote)
: ---
Assigned To: Brett Wilson
:
Mentors:
: 98830 138933 214532 230065 232690 255551 260448 261148 266798 267120 271273 271522 273192 273832 274883 277286 277773 277824 279113 279467 279933 280549 282346 282852 283172 283544 285329 287254 287591 287822 288450 288454 289533 291400 292621 293013 293789 294992 295135 297581 298121 300815 303396 304701 309193 312628 314426 (view as bug list)
Depends on:
Blocks: 236647 280625 282051 295540
  Show dependency treegraph
 
Reported: 2004-06-02 20:23 PDT by mark thompson
Modified: 2013-01-11 18:20 PST (History)
83 users (show)
asa: blocking1.8rc1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (7.77 KB, patch)
2004-10-03 11:47 PDT, Peter Van der Beken [:peterv]
asaf: review+
bzbarsky: superreview+
Details | Diff | Review
nView Desktop Manager - Windows tab (88.82 KB, image/png)
2005-03-06 18:50 PST, Thomas K. (:tom)
no flags Details
Patch to fix bad placement on Windows (6.65 KB, patch)
2005-10-19 17:38 PDT, Brett Wilson
mikepinkerton: review+
roc: superreview+
asa: approval1.8rc1+
Details | Diff | Review

Description mark thompson 2004-06-02 20:23:34 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

I have a mac with two screens. The screen with the menu bar is on the right,
and firefox is on the left screen. If I right-click to bring up a menu, the
menu pops up on the right (primary) screen, not over the browser window as expected.

Reproducible: Always
Steps to Reproduce:
1. Duplicate details above (two screens, firefox on non-primary screen)
2. Select right mouse button (it is good to have several buttons)
3. Observe that pop-up menu is on main screen.

Actual Results:  
see 3 above

Expected Results:  
Generally, the menus pop up where the mouse pointer is.

Setting the severity to "normal" because there is no "very irritating" setting
Comment 1 José Jeria 2004-06-02 23:48:04 PDT
Can you please retest with a nightly branch build? A fix for this in Bug 135079
was checked in only 2-3 days ago. Dont know though if it fixed the bug on Mac.
Comment 2 Bruce Davidson 2004-07-31 06:58:42 PDT
*** Bug 251927 has been marked as a duplicate of this bug. ***
Comment 3 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-09-30 16:19:26 PDT
*** Bug 254882 has been marked as a duplicate of this bug. ***
Comment 4 John Green 2004-10-01 07:46:19 PDT
This behaviour still exists in 1.0 Release Candidate for Mac (Mozilla/5.0
(Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10).
Comment 5 Peter Van der Beken [:peterv] 2004-10-03 11:47:11 PDT
Created attachment 160941 [details] [diff] [review]
v1

Use the right screen to reposition a nsMenuPopupFrame.
Comment 6 jhp (no longer active) 2004-10-04 07:44:14 PDT
peterv: were you able to actually test this patch on multiple monitors?
Comment 7 Peter Van der Beken [:peterv] 2004-10-04 07:49:30 PDT
Yes, but if anyone else can test them too it'd be good to have confirmation that
it works elsewhere. ;-)
Comment 8 jhp (no longer active) 2004-10-04 08:02:08 PDT
Comment on attachment 160941 [details] [diff] [review]
v1

Looks good.
Comment 9 Simon Paquet [:sipaq] 2004-10-30 07:58:27 PDT
*** Bug 138905 has been marked as a duplicate of this bug. ***
Comment 10 Simon Paquet [:sipaq] 2004-10-30 07:58:43 PDT
*** Bug 266798 has been marked as a duplicate of this bug. ***
Comment 11 Ali Ebrahim 2004-10-30 08:10:02 PDT
This is a pretty nasty UI quirk. Requesting blocking-aviary1.0 since we're now
shipping Mac 1.0 along with Windows and Linux.
Comment 12 Jannik Sueltz 2004-11-11 04:36:42 PST
Got the same problem.
Comment 13 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-11-12 13:37:08 PST
*** Bug 269509 has been marked as a duplicate of this bug. ***
Comment 14 Sukhjeet Batth 2004-11-12 13:44:09 PST
(In reply to comment #5)
> Created an attachment (id=160941)
> v1
> 
> Use the right screen to reposition a nsMenuPopupFrame.

Can somebody please post directions on how to use this attachment to fix the
issue?  I'm not a programmer and this is a really irritating bug.  Thanks.
Comment 15 Jo Hermans 2004-11-22 12:59:07 PST
*** Bug 271273 has been marked as a duplicate of this bug. ***
Comment 16 OstGote! 2004-11-23 00:40:40 PST
Two dupes are PC/Win32, so Hardware/OS should be changed to All/All. And the
summary needs an update too.
Comment 17 jhp (no longer active) 2004-11-23 08:30:09 PST
Changing summary and Hardware/OS to reflect that this is a cross-platform bug.
Comment 18 OstGote! 2004-11-24 05:49:50 PST
*** Bug 271522 has been marked as a duplicate of this bug. ***
Comment 19 OstGote! 2004-12-01 05:18:39 PST
*** Bug 260448 has been marked as a duplicate of this bug. ***
Comment 20 OstGote! 2004-12-01 05:23:39 PST
corresponding Seamonkey bug is Bug 98830 (with patch for the same file)
Comment 21 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-02 22:39:13 PST
*** Bug 255551 has been marked as a duplicate of this bug. ***
Comment 22 Jo Hermans 2004-12-05 07:05:16 PST
*** Bug 273192 has been marked as a duplicate of this bug. ***
Comment 23 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-05 20:22:49 PST
zac@zacbowling.com, please don't touch the blocking flags.
Comment 24 Zac Bowling 2004-12-05 21:42:39 PST
Happens in Linux all flavors using dual head or single head /w Nvidia TwinView
drivers as well.
Comment 25 sylvainmandon 2004-12-07 06:16:15 PST
On windows XP with dual screen with firefox 1.0, the menu always pops up on the
screen (either primary or secondary) on which firefox was launched even after
firefox was moved to the other screen (secondary or primary respectively). 
Comment 26 Olivier Cahagne 2004-12-08 21:58:03 PST
*** Bug 273832 has been marked as a duplicate of this bug. ***
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-16 04:00:02 PST
*** Bug 274883 has been marked as a duplicate of this bug. ***
Comment 28 Hans Nouwens 2004-12-16 04:12:48 PST
Thunderbird has the same problem, just the other way around, left appears on the
right, right on left.
See: http://meta.citg.tudelft.nl/mozilla_menu/
Comment 29 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-16 04:30:13 PST
Same thing as bug 98830. Both have patches, but that work should probably be
consolidated. peterv and DanM are the two patch submitters.
Comment 30 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-12-16 04:43:53 PST
Comment on attachment 160941 [details] [diff] [review]
v1

restoring r= from javeier
Comment 31 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-12-20 10:48:35 PST
*** Bug 275399 has been marked as a duplicate of this bug. ***
Comment 32 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-12-20 10:50:37 PST
*** Bug 275395 has been marked as a duplicate of this bug. ***
Comment 33 Phil Ringnalda (:philor) 2004-12-22 19:47:14 PST
*** Bug 275755 has been marked as a duplicate of this bug. ***
Comment 34 Simon Paquet [:sipaq] 2005-01-06 10:47:17 PST
*** Bug 98830 has been marked as a duplicate of this bug. ***
Comment 35 Simon Paquet [:sipaq] 2005-01-06 10:49:08 PST
*** Bug 277286 has been marked as a duplicate of this bug. ***
Comment 36 Allen Pike 2005-01-08 16:19:12 PST
While this bug is annoying as reported (side-by-side displays) it is much more
annoying using vertically-placed displays. I have my second display BELOW my
first rather than beside. With this setup, popup controls appear on the correct
display, but they pop UP rather than down from their origin. As a result, if you
have Firefox below your main monitor, and start typing a URL, the popup
autocomplete box of URLs totally obscures what you're typing! Obviously not
being able to see URLs as you type them makes things quite unpleasant. Hopefully
the patch fixes this problem as well.

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5)
Gecko/20041110 Firefox/1.0
Comment 37 Jo Hermans 2005-01-10 07:17:06 PST
*** Bug 277773 has been marked as a duplicate of this bug. ***
Comment 38 Jo Hermans 2005-01-10 07:19:55 PST
see the description in bug 277773 :

> I noticed that the Vertical cooridinate of the popup windows seem to be correct
> on the primary monitor.  The horizontal coordinate seems to be calculated on an
> artifically capped value, that is the limit of the primary monitor.
Comment 39 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-10 15:06:33 PST
*** Bug 277824 has been marked as a duplicate of this bug. ***
Comment 40 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-01-10 20:02:17 PST
*** Bug 267120 has been marked as a duplicate of this bug. ***
Comment 41 Jim Willis 2005-01-11 08:14:42 PST
Okay, my system (WinXP) is working now!  It is literally like magic.  I did not
even rebooted, but I am working on the secondary screen and it correctly does
popups and the  like.  

Yesterday I did the following thay may be related to the XUL subsystem.
1) Installed the lastest version of the Calendar System in both FireFox and
Thunderbird.
2) Configured Thunderbird as email client (I had been putting it off)
3) Change Thunderbird launch cmd line to include --console switch.
4) I am starting to use Thunderbird

A date search of my program files directory does only shows that logs and ini
have changed in the last 2 days.

Let me know if there is something you want me to look at or post.
Comment 42 Gregory Smith 2005-01-19 13:08:12 PST
(In reply to comment #25)
 
> 

I am seeing the same thing under xp with Mozilla 1.7.5, but I don't know how to
launch on #2 to test that case (I can place a shcut on #2, but dclicking it
still launches on #1). When app is on #2, menus, pulldown url bar, right-click
popups, hover popups appear in correct vertical place at left edge of #1.
Right-click on title bar is OK. right-click on 'lock' causes security info to
appear on #1

Pulldown boxes in the HTML content are ok.

XP, Radeon X300, both screens 1280x1024, #2 to left of #1
Comment 43 Davor Cubranic 2005-01-19 14:37:45 PST
(In reply to comment #42)
 
> I am seeing the same thing under xp with Mozilla 1.7.5, but I don't know how to
> launch on #2 to test that case

Try closing Mozilla with your last remaining window on monitor #2. When I did
that , the next time it started on monitor #2 and somehow context menus started
working on both monitors.
Comment 44 Kevin Brosnan 2005-01-20 06:34:41 PST
*** Bug 279113 has been marked as a duplicate of this bug. ***
Comment 45 Bruce Davidson 2005-01-23 05:44:10 PST
*** Bug 279467 has been marked as a duplicate of this bug. ***
Comment 46 Asa Dotzler [:asa] 2005-01-25 13:10:10 PST
*** Bug 214532 has been marked as a duplicate of this bug. ***
Comment 47 Asa Dotzler [:asa] 2005-01-25 13:10:54 PST
*** Bug 230065 has been marked as a duplicate of this bug. ***
Comment 48 Matthias Versen [:Matti] 2005-01-26 11:53:33 PST
*** Bug 279933 has been marked as a duplicate of this bug. ***
Comment 49 Simon Fraser 2005-01-28 17:57:55 PST
I wonder if this is related?
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsScreenManagerMac.cpp#118
Comment 50 Kevin Brosnan 2005-01-31 09:59:47 PST
*** Bug 280549 has been marked as a duplicate of this bug. ***
Comment 51 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-02-02 15:35:20 PST
*** Bug 280853 has been marked as a duplicate of this bug. ***
Comment 52 Kevin Brosnan 2005-02-07 19:43:29 PST
*** Bug 281422 has been marked as a duplicate of this bug. ***
Comment 53 Simon Paquet [:sipaq] 2005-02-15 23:57:09 PST
*** Bug 282346 has been marked as a duplicate of this bug. ***
Comment 54 Peter Ritchie 2005-02-19 06:13:04 PST
Seems to work fine in Firefox when it is initially opened on the second monitor.
 Even when moving from one monitor to the other.
Comment 55 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-02-19 09:22:01 PST
*** Bug 282852 has been marked as a duplicate of this bug. ***
Comment 56 Dan M 2005-02-21 08:19:51 PST
*** Bug 232690 has been marked as a duplicate of this bug. ***
Comment 57 Simon Paquet [:sipaq] 2005-02-22 08:13:48 PST
*** Bug 283172 has been marked as a duplicate of this bug. ***
Comment 58 José Jeria 2005-02-23 08:02:23 PST
*** Bug 283320 has been marked as a duplicate of this bug. ***
Comment 59 PikeUK 2005-03-03 08:05:52 PST
*** Bug 283544 has been marked as a duplicate of this bug. ***
Comment 60 Thomas K. (:tom) 2005-03-06 18:50:32 PST
Created attachment 176531 [details]
nView Desktop Manager - Windows tab

Alright, I looked a lot deeper into Bug 283544 (my dupe) and found that the
problem is affected by this nView checkbox.  I'll go into detail on how things
are affected:

1) When spanning is disabled, IE "snaps" back to the main window or secondary
window when you try to stretch it across monitors, snapping to whichever has
more than 50% (it seems) of the window.  It will resize itself if it is wider
than the monitor to fit the monitor.  Instead of doing this action, Firefox
will stretch into the secondary monitor and not snap/resize back.  As well,
when one tries to do a dropdown while stretched, the dropdown is treated like a
new window and sent to the "new window home".

2) When spanning is enabled, the dropdown windows spawn exactly where they
should be and neither browser snaps back to a display.	I don't see a need to
expand on this further.

3) When spanning is disabled yet one uses the "Maximize to Desktop" button
(added by nvidia drivers, NOT the default "Maximize" button), the software
allows the window to break this rule and span both desktops.  IE and it's
dropdowns are not negatively affected by this, they span both desktops too. 
Firefox's, on the other hand, are sent back to the "correct" desktop.

I hope all this data is useful.  If any more tests are needed, please ask.  Oh,
and I really don't know what the "child window" checkbox does, I suppose the
javascript alerts and such might qualify.
Comment 61 Brian Ryner (not reading) 2005-03-07 18:51:59 PST
Comment on attachment 160941 [details] [diff] [review]
v1

Sorry Boris, I'm going to send this one your way because I know you were just
in this code not too long ago and probably have it somewhat fresh in your mind.
Comment 62 Mark 2005-03-08 01:53:22 PST
Also affect Intel GMA900 Graphics on my machine.

The menues etc appear on the primary monitor instead of the correct one.
Comment 63 José Jeria 2005-03-08 13:55:37 PST
*** Bug 285329 has been marked as a duplicate of this bug. ***
Comment 64 Boris Zbarsky [:bz] 2005-03-08 22:41:02 PST
So... wouldn't it make more sense to fix the known issue with
nsGlobalWindow::GetScreen (to whit, that it returns the wrong one sometimes)? 
That would incidentally fix this bug, but also the other bugs we have on
GetScreen (bug 62395, to be exact).

It looks to me like the code you added here should instead live in
nsGlobalWindow::GetScreen, or that code should do something else to be smarter.
Comment 65 Peter Van der Beken [:peterv] 2005-03-09 00:02:54 PST
Well, do we want to change GetScreen so that it returns the value that we need
here? Note that for example a window could be 90% on screen A and we'd still
want the contextual menu on screen B if you clicked somewhere in the 10% that
are in screen B. Would you expect GetScreen to return B in that case?
I'm not sure how bug 62395 is related?
Comment 66 Boris Zbarsky [:bz] 2005-03-09 10:18:35 PST
Comment on attachment 160941 [details] [diff] [review]
v1

>Index: layout/xul/base/src/nsMenuPopupFrame.cpp
>+  PRUint32 numberOfScreens;
>+  screenMgr->GetNumberOfScreens(&numberOfScreens);

Why?  Just using the rects no matter what should do the right thing (I just
read all the impls of ScreenForRect to verify this).....

>+    // Use the same screen as the parent is using.
>+    screenMgr->ScreenForRect(screenParentWidgetRect.x,
>+                             screenParentWidgetRect.y, 
>+                             screenParentWidgetRect.width,
>+                             screenParentWidgetRect.height,

This is wrong, imo, since screenParentWidgetRect has 0 width and height.... 
Not only that, but this has the wrong offset too, I think.

You probably want to be using screenFrameParentRect here, but in pixels.

sr=bzbarsky with that addressed.
Comment 67 Peter Van der Beken [:peterv] 2005-03-09 14:55:23 PST
(In reply to comment #66)
> Why?  Just using the rects no matter what should do the right thing (I just
> read all the impls of ScreenForRect to verify this).....

I didn't see the point in going through the trouble of getting the screen for a
rect if there's only one screen.

> This is wrong, imo, since screenParentWidgetRect has 0 width and height.... 
> Not only that, but this has the wrong offset too, I think.
> 
> You probably want to be using screenFrameParentRect here, but in pixels.

Woops, you're right. I'll use screenParentFrameRect.
Comment 68 Boris Zbarsky [:bz] 2005-03-09 19:30:04 PST
> Woops, you're right. I'll use screenParentFrameRect.

Actually, I was thinking about this some more, and it seems we still have a sort
of problem if the parent frame rect overlaps a screen edge... I guess we'll
always put the menu on the screen where "most" of the parent is, instead of on
the one that has more space (which would be the desired behavior in general, I
think).  I guess that's ok, though....
Comment 69 Peter Ritchie 2005-03-10 05:29:26 PST
(In reply to comment #68)
Why not open the context menu on the screen where the mouse was pressed?

> Actually, I was thinking about this some more, and it seems we still have a sort
> of problem if the parent frame rect overlaps a screen edge... I guess we'll
> always put the menu on the screen where "most" of the parent is, instead of on
> the one that has more space (which would be the desired behavior in general, I
> think).  I guess that's ok, though....

Comment 70 Thomas K. (:tom) 2005-03-10 06:05:04 PST
Peter: there's a option in the nView manager to open windows where your mouse is
(I'm pretty sure...), and all that, and I have it set to display one.  If I use
IE across two screens (using the 'full screen' button added by nvidia, which
works while 'span screens' is disabled) and doppleclicken the form on google,
you will get the dropdown list and it will span screens.  It will appear below
the google box.

I don't know why you'd want to move the _entire_ box to one screen, because it
would look abnormal as it would be shifted away from the box.  While it does
make sense (don't have to look from screen to screen to see the whole line), it
should default to span screens.  If that's not possible as fast as "drop the box
on the screen you clicked on", then it can wait, but if it's possible now I
don't see a reason not to do it.
Comment 71 Peter Ritchie 2005-03-10 06:40:17 PST
(In reply to comment #70)

That's pretty specific to nVidia.  If I do the same thing in IE without nVidia
by sizing the window to span two screens the context menu NEVER spans two
screens, if the menu can't be displayed to the right of the mouse click point it
is displayed to the left instead.  That's pretty typical of most Windows apps
too (standard for those that actually work on a second monitor).

I would imagine that spanning that menu across two screens is a driver-specific
thing (i.e. nVidia-specific).  If you try and open a context menu on monitor one
whose resolution is 1024x768 at postion 1020, 384 it might span two monitors
with nVidia; but not with others.

It's the same with the mouse cursor; on my video driver it NEVER spans two screens.

If 99% of the Windows apps show the context menu in this way then I don't think
it's worth the time to do anything differently, expecially considering nVidia is
not the only video driver.

> Peter: there's a option in the nView manager to open windows where your mouse is
> (I'm pretty sure...), and all that, and I have it set to display one.  If I use
> IE across two screens (using the 'full screen' button added by nvidia, which
> works while 'span screens' is disabled) and doppleclicken the form on google,
> you will get the dropdown list and it will span screens.  It will appear below
> the google box.
> 
> I don't know why you'd want to move the _entire_ box to one screen, because it
> would look abnormal as it would be shifted away from the box.  While it does
> make sense (don't have to look from screen to screen to see the whole line), it
> should default to span screens.  If that's not possible as fast as "drop the box
> on the screen you clicked on", then it can wait, but if it's possible now I
> don't see a reason not to do it.

Comment 72 Boris Zbarsky [:bz] 2005-03-10 09:42:14 PST
> Why not open the context menu on the screen where the mouse was pressed?

Why not read the patch?  That's what it does.  I was talking about the _other_
changes the patch makes -- it changes the screen used for non-context menus too,
in some cases.  See also summary of this bug, which clearly talks about
non-context menus.

And please don't quote long comments in their entirety....
Comment 73 R.K.Aa. 2005-03-10 22:12:17 PST
*** Bug 285638 has been marked as a duplicate of this bug. ***
Comment 74 José Jeria 2005-03-22 12:34:57 PST
*** Bug 287254 has been marked as a duplicate of this bug. ***
Comment 75 Kevin Brosnan 2005-03-24 10:17:12 PST
*** Bug 287591 has been marked as a duplicate of this bug. ***
Comment 76 José Jeria 2005-03-26 09:45:17 PST
*** Bug 287822 has been marked as a duplicate of this bug. ***
Comment 77 Steve England [:stevee] 2005-03-31 08:05:42 PST
*** Bug 288454 has been marked as a duplicate of this bug. ***
Comment 78 OstGote! 2005-03-31 16:03:28 PST
*** Bug 288450 has been marked as a duplicate of this bug. ***
Comment 79 Matthias Versen [:Matti] 2005-04-08 08:35:59 PDT
*** Bug 289533 has been marked as a duplicate of this bug. ***
Comment 80 Matthias Versen [:Matti] 2005-04-12 07:09:47 PDT
*** Bug 289533 has been marked as a duplicate of this bug. ***
Comment 81 Kevin Brosnan 2005-04-21 19:32:01 PDT
*** Bug 291400 has been marked as a duplicate of this bug. ***
Comment 82 Steve England [:stevee] 2005-05-02 08:19:12 PDT
*** Bug 292621 has been marked as a duplicate of this bug. ***
Comment 83 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-05-05 09:20:44 PDT
*** Bug 293013 has been marked as a duplicate of this bug. ***
Comment 84 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-05-22 11:55:02 PDT
*** Bug 295135 has been marked as a duplicate of this bug. ***
Comment 85 Steve England [:stevee] 2005-05-23 09:11:17 PDT
*** Bug 295242 has been marked as a duplicate of this bug. ***
Comment 86 timeless 2005-05-27 07:44:17 PDT
*** Bug 294992 has been marked as a duplicate of this bug. ***
Comment 87 Jorge Santos 2005-06-01 10:26:29 PDT
I'm running FF 1.0.4 and i still have this problem, shouldn't this version of FF
have been released with this problem fixed ?

I'm running on a ATI 9600 and using UltraMon as a dual head managing program.

And all menus popup on my primary screen if i start windows with only 1 screen
and then swich to two
Comment 88 Boris Zbarsky [:bz] 2005-06-01 10:33:40 PDT
> I'm running FF 1.0.4 

That's using a layout engine from April 2004.

In any case, this bug isn't fixed yet, even on trunk.  That's why it's "Status:
NEW".
Comment 89 José Jeria 2005-06-14 12:04:11 PDT
*** Bug 297581 has been marked as a duplicate of this bug. ***
Comment 90 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-06-18 14:31:22 PDT
*** Bug 298121 has been marked as a duplicate of this bug. ***
Comment 91 Jo Hermans 2005-07-11 11:25:26 PDT
*** Bug 300378 has been marked as a duplicate of this bug. ***
Comment 92 Kevin Brosnan 2005-07-14 11:51:21 PDT
*** Bug 300815 has been marked as a duplicate of this bug. ***
Comment 93 Dave Townsend [:mossop] 2005-08-04 10:15:21 PDT
*** Bug 261148 has been marked as a duplicate of this bug. ***
Comment 94 Dave Townsend [:mossop] 2005-08-04 10:15:37 PDT
*** Bug 303396 has been marked as a duplicate of this bug. ***
Comment 95 José Jeria 2005-08-06 06:12:09 PDT
*** Bug 303653 has been marked as a duplicate of this bug. ***
Comment 96 edward miller 2005-08-12 08:52:00 PDT
I have the same bug.  Using the nightly build of Camino of August 4, 2005, with
my 12" PB [1.33 MHz] left screen having the menu bar and Camino on the 20"
monitor right screen, involking the print dialog box gives this bug.  The dialog
box appears on the PB screen, not on the screen over, or within, the Camino window. 

The print dialog box being active makes all other windows inactive, so I use the
preview function of the print dialog box to insure that the correct window
content is about to be printed.  This is irritating, but easily worked around by
using preview.  This bug is reproducable.   Using Mac OS 10.3.9.
Comment 97 Jo Hermans 2005-08-15 07:56:26 PDT
*** Bug 304701 has been marked as a duplicate of this bug. ***
Comment 98 Mike Pinkerton (not reading bugmail) 2005-08-15 10:15:50 PDT
the print dialog going to the main screen in camino has nothing (zip, zero,
zilch) to do with this bug. please ignore that last comment in this discussion.
Comment 99 Matt Heinrichs 2005-08-22 08:27:49 PDT
I have been having the same problem through Firefox 1.0 and now on Deer Park
Alpha 2 as well.
It generally works correctly.  I switch from one to two monitors frequently
(dock/undock).  Have no idea what triggers the start of this behaviour.  If I
have both Deer Park Alpha 2 and Thunderbird (1.0) open at the same time,
however, both applications generally (always?) experience it at the same time.
If I restart either app, it will begin to work correctly again for that
application - the other application will continue to experience the problem. 
Nothing short of restarting the application will correct the problem.

This is on a windows XP machine - HP/Compaq laptop NC6000, ATI mobility 9600.
Comment 100 Wayne Mery (:wsmwk, use Needinfo for questions) 2005-08-26 07:41:46 PDT
possible dups?: Bug 138933 Bug 291434

patch not checked in?
Comment 101 Miguel Dias 2005-09-14 20:31:20 PDT
I noticed this same bug on firefox 1.5 beta 1 (windows xp). If firefox runs on
my left display (1 - primary), all menu's appear correctly, if I move firefox to
my right display (2) then all menu's appear on screen 1. On mozilla is works fine.

here are both versions I use.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Comment 102 Miguel Dias 2005-09-15 08:37:35 PDT
(In reply to comment #101)
> I noticed this same bug on firefox 1.5 beta 1 (windows xp). If firefox runs on
> my left display (1 - primary), all menu's appear correctly, if I move firefox to
> my right display (2) then all menu's appear on screen 1. On mozilla is works fine.
> 
> here are both versions I use.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511


hmmmm new update, I droped the nview desktop manager and changed to Ultramon,
and after restarting firefox's problem went away. 

:) 
Comment 103 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-09-19 19:27:02 PDT
*** Bug 309238 has been marked as a duplicate of this bug. ***
Comment 104 klk19 2005-09-19 21:23:26 PDT
The problem is still present on OSX Firefox 1.5 beta 1.

At least on the Mac, this looks like an initialization bug. If you start Firefox
with both monitors active, then drop down menus appear where you expect them. It
makes no difference whether firefox is on the primary or secondary screen, left
or right, or if the window spans BOTH monitors. The menus even work when you
start with two monitors, go to one monitor, and back to two monitors using a
different device running at different resolutions.

{Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6}  PowerBook ATY,RageM6
Comment 105 Phil Ringnalda (:philor) 2005-09-19 23:22:00 PDT
*** Bug 309193 has been marked as a duplicate of this bug. ***
Comment 106 Matt Heinrichs 2005-10-13 07:47:55 PDT
This bug still exists in Firefox 1.5 Beta 2 (running on WinXP, ATI drivers).
Also exists in Thunderbird 1.5 Beta 2.

If I exit and restart Firefox, the problem goes away.  Haven't drilled into what
triggers it, but I dock and undock a lot (it's a laptop).  It may be related to
what mode it's in when I start it up, or just get's confused by the changes.
Comment 107 OstGote! 2005-10-16 10:32:07 PDT
*** Bug 312628 has been marked as a duplicate of this bug. ***
Comment 108 Darin Fisher 2005-10-18 19:46:45 PDT
I can reproduce this easily in Windows with FF 1.5b2 by loading it on my laptop
with only the laptop display enabled.  Then, without closing FF, if I connect my
laptop to an external monitor and have it display on both monitors, I hit this
bug.  It seems to me that we must have some code that is caching the state of
the display size(s) and not updating the cached state when the display
configuration changes.

I think this is a serious usability problem for laptop users who frequently dock
with an external display.  We should really try to fix this for 1.5 if possible.
Comment 109 Brett Wilson 2005-10-19 10:43:33 PDT
The problem seems to be that gfx/src/windows/nsDeviceContextWin.cpp caches the
number of screens in sNumberOfScreens. This value is initialized when the app
starts, and is not updated if the number of screens increases. When there is
only one screen, it does not do the checks to see which screen popups should
appear on and always puts them on the first screen.

When people dock their laptop or do certain changes with nView, it has the
effect of increasing the number of screens. If you have two monitors and want to
reproduce the problem: Disable your second monitor (uncheck "Extend my Windows
desktop onto this monitor" in display properties | settings. Start firefox (or
any other Moz app). Re-enable the second monitor and move the window to the
second monitor. All menus will appear on the first monitor.

Commenting out these checks agains sNumberOfScreens == 1 fixes the problem (at
least for me). This will impact performance for the common case of one monitor.
I'll see if this value can be easily updated.
Comment 110 Asa Dotzler [:asa] 2005-10-19 11:35:23 PDT
we'd nee a patch landed and verified (and tested to ensure nothing broke from
the landing) on the trunk before we'll consider something like this for the
branch. I feel the pain too :-)
Comment 111 Brett Wilson 2005-10-19 17:38:56 PDT
Created attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

The previous patch (correct me if I'm wrong) changes the popup code see if the
screen is wrong and move the popup accordingly. This is a workaround for the
fact that the popup pixks the wrong screen to appear on sometimes.

This patch fixes the underlying cause of the problem on Windows, which is that
the number of screens is cached (as per my above comment). It removes the
caching code entirely and always computes the correct screen for a popup to
appear on.

This is a very low risk patch. It only removes (and re-indents) code; nothing
is added or changed. The result is that popup will appear on the screen in
which the majority of the parent window resides, which was the original design.

When the main window overlaps two screens, this can be a little weird sometimes

and should probably be fixed (as suggested in comment 64 and others). But I
think changes to this behavior are beyond the scope of this bug.

Performance impact should be minimal. This code is not called during layout or
Window resize, and only when new windows are created. Impact will be 0 for
people with multiple monitors, and otherwise you will be charged a system call
to compute the correct monitor (should be very fast if there is only one) and
a nsIScreen cache lookup,

This patch does not fix anything for Mac, which, from the above comments, seems

to have a similar issue. The Mac display context code does not cache the number

of monitors, which is what was causing the problem on Windows. If this problem
exists on the Mac (I can't test this), it has a slightly different cause.
Comment 112 Darin Fisher 2005-10-19 19:23:19 PDT
Comment on attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

Looks good to me, but I defer to roc.  r=darin
Comment 113 Darin Fisher 2005-10-19 19:27:26 PDT
Comment on attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

Actually, cvs blame says that pinkerton touched this code last, so I'd really
like him to review this as well.  See revision 3.50 for bug 21942 and bug
32611.	It ooks like the patch that he checked in introduced the code that is
being removed by this patch.
Comment 114 Asa Dotzler [:asa] 2005-10-20 11:28:31 PDT
not going to block but I'm interested in risk analysis from roc and pav. I
suspect we're too late in the game to take this.
Comment 115 Mike Pinkerton (not reading bugmail) 2005-10-20 13:56:13 PDT
i don't disagree that the caching seems not too helpful, especially these days,
but I'm pretty sure it was put there for a reason (to help speed up xp menus
which were dog slow back in the day). I don't remember for certain, but i don't
think this is a case of premature optimization.

Brett is going to test on win98 to make sure this doesn't substantially regress
performance. If that is promising, i'm ok with this patch.
Comment 116 Brett Wilson 2005-10-20 17:58:12 PDT
These timings are for a ~3Ghz machine with a debug build for 100,000 calls of
the code that is now executed by removing caching. (So, with caching, these
numbers would be about 0.)

WinXP, multiple monitors = 140ms
Win98, single monitor running in virtual machine = 350ms

These numbers do not scale linearly testing different values of the repeat. But
are still very small.

This code gets called about 8 times per popup. Contrary to my above assertion,
it can get called during page load. I think it happens when new iframes are
created, and they get a corresponding view.

I feel confident that performance is good. Even if a typical machine is 100x
slower than mine (30Mhz!), this will add 2ms to popup menus if we assume linear
scaling of query time. It will probably be several times more in practice
because performance does not scale down linearly, but it will still be
unnoticable. Non debug builds should be slightly faster.
Comment 117 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-10-20 19:24:28 PDT
Comment on attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

I believe it!
Comment 118 Mike Pinkerton (not reading bugmail) 2005-10-21 06:30:24 PDT
Comment on attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

r=pink

does the same code exist on mac & linux? should we remove it there as well?
Comment 119 Brett Wilson 2005-10-21 09:40:15 PDT
Our Linux implementation is not multi-monitor aware.

I looked at the Mac code, and it was not obvious that there was the same error
(it does not cache the number of monitors like the Windows code). However, as
some people have complained about the problem on Mac, it might be good if
somebody familiar with this stuff could take a look at it.
Comment 120 Darin Fisher 2005-10-21 10:31:07 PDT
Comment on attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

OK, let's get this on the trunk so we can get drivers to approve it for the
branch ;-)
Comment 121 Darin Fisher 2005-10-21 10:59:48 PDT
fixed-on-trunk
Comment 122 Darin Fisher 2005-10-21 15:31:05 PDT
fixed1.8

If there remains a Mac-specific version of this bug, then I think we ought to
create a new bug report for that for easier patch tracking.
Comment 123 klk19 2005-10-28 13:45:53 PDT
Using the latest DeerPark build,
[Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051028 Firefox/1.6a1]
 the bug now behaves differently on a Mac (OS X 10.4.2).

If DeerPark is opened on a single monitor configuration, then a second monitor
is added, DeerPark window shifts to the correct main monitor. Drop down
menues properly follow the window to the main monitor. 

If you then move the window to the secondary monitor, the drop down menues 
stay on the main monitor.


If you open DeerPark with two monitors, the drop down menues appear over the
window correctly. This works even if you have one window on the main monitor
and another on the secondary monitor or the window spans the monitors.

Looks like the PC fixed got part of the Mac problem but not all.
Comment 124 Jo Hermans 2005-10-28 14:09:52 PDT
> Looks like the PC fixed got part of the Mac problem but not all.

Only Win32-specific code was touched (nsDeviceContextWin.h / nsDeviceContextWin.cpp), so it can't be a regression. There was no caching of the "NumberOfScreens" on Mac or Linux at all. Please file another bug for this issue. 
Comment 125 Jo Hermans 2005-10-30 11:13:34 PST
*** Bug 314426 has been marked as a duplicate of this bug. ***
Comment 126 klk19 2005-10-30 18:25:07 PST
I filed another bug AS REQUESTED.

Would you PLEASE decide whether you want to mark 245418 as open
   or
you want another bug to track the problem on the Mac.

The problem is ***NOT FIXED*** on the Mac.

klk19
Comment 127 Boris Zbarsky [:bz] 2005-10-30 18:31:41 PST
> I filed another bug AS REQUESTED.

What bug number?
Comment 128 Brett Wilson 2005-10-30 21:48:28 PST
I think Darin's suggestion is best: open a new bug for Mac. The bug on the Mac is probably due to similar assumptions in the code, but not the same problem in the same place (so far as I can see).

Changed the OS to WinXP in this bug (hmm, I'd like it if there were a general "Windows" option) to make this more clear.
Comment 129 kasper 2005-10-30 22:22:49 PST
These are the rules about how windows (and other items) are handled and displayed by Windows on systems with multiple monitors:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/monitor_5isz.asp
Comment 130 Brett Wilson 2005-10-30 23:06:30 PST
This bug, fixing some errant behavior on Windows, has been resolved. While I agree that certain multi-monitor behavior of Mozilla could be improved, that belongs in another bug. 
Comment 131 klk19 2005-10-31 06:40:43 PST
> ------- Comment #127 From Boris Zbarsky 2005-10-30 18:31 PST [reply] -------

>> I filed another bug AS REQUESTED.

> What bug number?

*** Bug 314426 which was posted here as a duplicate 245418. ***

Bug 314426 still lists its status as "unconfirmed" on OS "MacOS X" and 
not as a "verified duplicate". This wasrequested refiling the same 
"errant behavior" as described and fixed on windows.
Comment 132 Wayne Mery (:wsmwk, use Needinfo for questions) 2005-10-31 06:57:30 PST
(In reply to comment #131)
> > ------- Comment #127 From Boris Zbarsky 2005-10-30 18:31 PST [reply] -------
> 
> >> I filed another bug AS REQUESTED.
> 
> > What bug number?
> 
> *** Bug 314426 which was posted here as a duplicate 245418. ***
> 
> Bug 314426 still lists its status as "unconfirmed" on OS "MacOS X" and 
> not as a "verified duplicate". This was requested refiling the same 
> "errant behavior" as described and fixed on windows.

Hmm, It's bug 314279 that mac users should flock to.

Comment 133 Boris Zbarsky [:bz] 2005-10-31 07:39:08 PST
> *** Bug 314426 which was posted here as a duplicate 245418. ***

Because you filed it in an 18-month old build. Chances are, what you're seeing _is_ bug 245418.
Comment 134 José Jeria 2005-12-12 12:14:44 PST
*** Bug 319965 has been marked as a duplicate of this bug. ***
Comment 135 Hideo Oshima 2005-12-22 17:16:45 PST
*** Bug 138933 has been marked as a duplicate of this bug. ***
Comment 136 Kevin Brosnan 2006-04-21 01:43:05 PDT
*** Bug 334921 has been marked as a duplicate of this bug. ***
Comment 137 Eric Warnke 2007-02-27 07:51:45 PST
Firefox 2.0.0.2 under OSX exhibits this problem.
Comment 138 Boris Zbarsky [:bz] 2007-02-27 09:25:47 PST
Eric, this bug is for the Windows builds (see the "OS" field at the top).  see comment 132 for the OSX issue.
Comment 139 guanxi 2007-04-18 09:52:41 PDT
*** Bug 324798 has been marked as a duplicate of this bug. ***
Comment 140 guanxi 2007-04-18 14:39:36 PDT
An (the?) equivalent Linux bug is bug 324798
Comment 141 Gordon P. Hemsley [:GPHemsley] 2009-02-14 01:03:56 PST
*** Bug 293789 has been marked as a duplicate of this bug. ***
Comment 143 emo88 2013-01-04 10:29:18 PST
Same bug apprears again on my Mac with Retina display (HiDPI).


(In reply to mark thompson from comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.6) Gecko/20040206 Firefox/0.8
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.6) Gecko/20040206 Firefox/0.8
> 
> I have a mac with two screens. The screen with the menu bar is on the right,
> and firefox is on the left screen. If I right-click to bring up a menu, the
> menu pops up on the right (primary) screen, not over the browser window as
> expected.
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Duplicate details above (two screens, firefox on non-primary screen)
> 2. Select right mouse button (it is good to have several buttons)
> 3. Observe that pop-up menu is on main screen.
> 
> Actual Results:  
> see 3 above
> 
> Expected Results:  
> Generally, the menus pop up where the mouse pointer is.
> 
> Setting the severity to "normal" because there is no "very irritating"
> setting
Comment 144 Steve.Guns 2013-01-09 22:34:49 PST
Confirmed, here as well. FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display
Comment 145 Yoav 2013-01-11 11:32:18 PST
Same here: FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display
Comment 146 Steve.Guns 2013-01-11 11:33:40 PST
Should this be filed as a new bug you think? Since this one is closed and might not get any attention anymore?
Comment 147 Boris Zbarsky [:bz] 2013-01-11 11:35:22 PST
Yes.  If there is no existing bug for the hidpi-specific issue, please file one.
Comment 148 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-01-11 18:20:00 PST
Retina issues with multiple monitors are being tracked in bug 828514.

Note You need to log in before you can comment on or make changes to this bug.