Bug 245418 (ContextMenuScreen)

menus and contextual menus open on wrong screen when using two/dual/multiple screens/monitors/displays

RESOLVED FIXED

Status

()

Core
XUL
RESOLVED FIXED
13 years ago
4 years ago

People

(Reporter: mark thompson, Assigned: Brett Wilson)

Tracking

(Blocks: 1 bug, {fixed1.8, polish})

Trunk
All
Windows XP
fixed1.8, polish
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: OSX issues are bug 314279)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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

13 years ago
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

13 years ago
*** Bug 251927 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 254882 has been marked as a duplicate of this bug. ***

Comment 4

13 years ago
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).

Updated

13 years ago
Flags: blocking-aviary1.0mac?
Created attachment 160941 [details] [diff] [review]
v1

Use the right screen to reposition a nsMenuPopupFrame.
peterv: were you able to actually test this patch on multiple monitors?
Yes, but if anyone else can test them too it'd be good to have confirmation that
it works elsewhere. ;-)
Comment on attachment 160941 [details] [diff] [review]
v1

Looks good.
Attachment #160941 - Flags: review+
Attachment #160941 - Flags: superreview?(bryner)

Comment 9

13 years ago
*** Bug 138905 has been marked as a duplicate of this bug. ***
*** Bug 266798 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
This is a pretty nasty UI quirk. Requesting blocking-aviary1.0 since we're now
shipping Mac 1.0 along with Windows and Linux.
Flags: blocking-aviary1.0mac? → blocking-aviary1.0?
Keywords: polish
Whiteboard: [have patch]
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Updated

13 years ago
Blocks: 236647

Comment 12

13 years ago
Got the same problem.
*** Bug 269509 has been marked as a duplicate of this bug. ***

Comment 14

13 years ago
(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

13 years ago
*** Bug 271273 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
Two dupes are PC/Win32, so Hardware/OS should be changed to All/All. And the
summary needs an update too.
Changing summary and Hardware/OS to reflect that this is a cross-platform bug.
OS: MacOS X → All
Hardware: Macintosh → All
Summary: contextual menus open on wrong screen when on a mac with two screens → contextual menus open on wrong screen when using two screens

Comment 18

13 years ago
*** Bug 271522 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Summary: contextual menus open on wrong screen when using two screens → menus and contextual menus open on wrong screen when using two screens

Comment 19

13 years ago
*** Bug 260448 has been marked as a duplicate of this bug. ***

Comment 20

13 years ago
corresponding Seamonkey bug is Bug 98830 (with patch for the same file)
Alias: ContextMenuScreen
*** Bug 255551 has been marked as a duplicate of this bug. ***

Comment 22

13 years ago
*** Bug 273192 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary1.0- → blocking-aviary1.0+

Updated

13 years ago
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
zac@zacbowling.com, please don't touch the blocking flags.
Flags: blocking-aviary1.0-

Comment 24

13 years ago
Happens in Linux all flavors using dual head or single head /w Nvidia TwinView
drivers as well.

Comment 25

13 years ago
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

13 years ago
*** Bug 273832 has been marked as a duplicate of this bug. ***
*** Bug 274883 has been marked as a duplicate of this bug. ***

Comment 28

13 years ago
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/
Same thing as bug 98830. Both have patches, but that work should probably be
consolidated. peterv and DanM are the two patch submitters.
Blocks: 98830
Component: Menus → XP Toolkit/Widgets: XUL
Flags: review+
Product: Firefox → Core
Version: unspecified → Trunk
Comment on attachment 160941 [details] [diff] [review]
v1

restoring r= from javeier
Attachment #160941 - Flags: review+
*** Bug 275399 has been marked as a duplicate of this bug. ***
*** Bug 275395 has been marked as a duplicate of this bug. ***
*** Bug 275755 has been marked as a duplicate of this bug. ***

Updated

13 years ago
No longer blocks: 98830
*** Bug 98830 has been marked as a duplicate of this bug. ***
*** Bug 277286 has been marked as a duplicate of this bug. ***
Assignee: firefox → nobody
QA Contact: bugzilla
Assignee: nobody → peterv
Flags: blocking-aviary1.1?

Comment 36

13 years ago
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

13 years ago
*** Bug 277773 has been marked as a duplicate of this bug. ***

Comment 38

13 years ago
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.
*** Bug 277824 has been marked as a duplicate of this bug. ***
*** Bug 267120 has been marked as a duplicate of this bug. ***

Comment 41

13 years ago
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

13 years ago
(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

13 years ago
(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

13 years ago
*** Bug 279113 has been marked as a duplicate of this bug. ***

Comment 45

13 years ago
*** Bug 279467 has been marked as a duplicate of this bug. ***

Comment 46

13 years ago
*** Bug 214532 has been marked as a duplicate of this bug. ***

Comment 47

13 years ago
*** Bug 230065 has been marked as a duplicate of this bug. ***
*** Bug 279933 has been marked as a duplicate of this bug. ***

Comment 49

13 years ago
I wonder if this is related?
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsScreenManagerMac.cpp#118

Comment 50

13 years ago
*** Bug 280549 has been marked as a duplicate of this bug. ***
*** Bug 280853 has been marked as a duplicate of this bug. ***

Comment 52

13 years ago
*** Bug 281422 has been marked as a duplicate of this bug. ***
*** Bug 282346 has been marked as a duplicate of this bug. ***

Comment 54

12 years ago
Seems to work fine in Firefox when it is initially opened on the second monitor.
 Even when moving from one monitor to the other.
*** Bug 282852 has been marked as a duplicate of this bug. ***

Comment 56

12 years ago
*** Bug 232690 has been marked as a duplicate of this bug. ***
*** Bug 283172 has been marked as a duplicate of this bug. ***

Comment 58

12 years ago
*** Bug 283320 has been marked as a duplicate of this bug. ***

Comment 59

12 years ago
*** Bug 283544 has been marked as a duplicate of this bug. ***

Comment 60

12 years ago
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 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.
Attachment #160941 - Flags: superreview?(bryner) → superreview?(bzbarsky)

Comment 62

12 years ago
Also affect Intel GMA900 Graphics on my machine.

The menues etc appear on the primary monitor instead of the correct one.

Comment 63

12 years ago
*** Bug 285329 has been marked as a duplicate of this bug. ***
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.
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 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.
Attachment #160941 - Flags: superreview?(bzbarsky) → superreview+
(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.
> 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

12 years ago
(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

12 years ago
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

12 years ago
(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.

> 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

12 years ago
*** Bug 285638 has been marked as a duplicate of this bug. ***
Blocks: 280625

Comment 74

12 years ago
*** Bug 287254 has been marked as a duplicate of this bug. ***

Comment 75

12 years ago
*** Bug 287591 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Summary: menus and contextual menus open on wrong screen when using two screens → menus and contextual menus open on wrong screen when using two screens/monitors

Comment 76

12 years ago
*** Bug 287822 has been marked as a duplicate of this bug. ***
*** Bug 288454 has been marked as a duplicate of this bug. ***

Comment 78

12 years ago
*** Bug 288450 has been marked as a duplicate of this bug. ***
*** Bug 289533 has been marked as a duplicate of this bug. ***
*** Bug 289533 has been marked as a duplicate of this bug. ***

Comment 81

12 years ago
*** Bug 291400 has been marked as a duplicate of this bug. ***
*** Bug 292621 has been marked as a duplicate of this bug. ***
*** Bug 293013 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.8b3?
Summary: menus and contextual menus open on wrong screen when using two screens/monitors → menus and contextual menus open on wrong screen when using two/dual/multiple screens/monitors/displays
*** Bug 295135 has been marked as a duplicate of this bug. ***
*** Bug 295242 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 163993

Updated

12 years ago
No longer blocks: 163993

Comment 86

12 years ago
*** Bug 294992 has been marked as a duplicate of this bug. ***

Comment 87

12 years ago
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
> 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

12 years ago
*** Bug 297581 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.8b3? → blocking1.8b3-
*** Bug 298121 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 282051

Comment 91

12 years ago
*** Bug 300378 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking-aviary1.1? → blocking1.8b4?

Comment 92

12 years ago
*** Bug 300815 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Flags: blocking-aviary2.0+

Updated

12 years ago
Blocks: 295540
*** Bug 261148 has been marked as a duplicate of this bug. ***
*** Bug 303396 has been marked as a duplicate of this bug. ***

Comment 95

12 years ago
*** Bug 303653 has been marked as a duplicate of this bug. ***

Comment 96

12 years ago
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

12 years ago
*** Bug 304701 has been marked as a duplicate of this bug. ***
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

12 years ago
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.
possible dups?: Bug 138933 Bug 291434

patch not checked in?

Comment 101

12 years ago
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

12 years ago
(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. 

:) 
*** Bug 309238 has been marked as a duplicate of this bug. ***

Comment 104

12 years ago
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
*** Bug 309193 has been marked as a duplicate of this bug. ***

Comment 106

12 years ago
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

12 years ago
*** Bug 312628 has been marked as a duplicate of this bug. ***

Comment 108

12 years ago
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.
Flags: blocking1.8rc1?
(Assignee)

Comment 109

12 years ago
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

12 years ago
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 :-)
(Assignee)

Comment 111

12 years ago
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.
Attachment #160941 - Attachment is obsolete: true
Attachment #200155 - Flags: superreview?(roc)
Attachment #200155 - Flags: review?(darin)

Comment 112

12 years ago
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
Attachment #200155 - Flags: review?(darin) → review+

Comment 113

12 years ago
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.
Attachment #200155 - Flags: review+ → review?(mikepinkerton)

Comment 114

12 years ago
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.
Flags: blocking1.8rc1? → blocking1.8rc1-
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.
(Assignee)

Comment 116

12 years ago
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 on attachment 200155 [details] [diff] [review]
Patch to fix bad placement on Windows

I believe it!
Attachment #200155 - Flags: superreview?(roc) → superreview+
Assignee: peterv → brettw
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?
Attachment #200155 - Flags: review?(mikepinkerton) → review+
(Assignee)

Comment 119

12 years ago
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

12 years ago
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 ;-)
Attachment #200155 - Flags: approval1.8rc1?

Comment 121

12 years ago
fixed-on-trunk
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Attachment #200155 - Flags: approval1.8rc1? → approval1.8rc1+

Comment 122

12 years ago
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.
Keywords: fixed1.8
Flags: blocking1.8b5-
Flags: blocking1.8b3-
Flags: blocking-aviary2.0+

Comment 123

12 years ago
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

12 years ago
> 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

12 years ago
*** Bug 314426 has been marked as a duplicate of this bug. ***

Comment 126

12 years ago
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
> I filed another bug AS REQUESTED.

What bug number?
(Assignee)

Comment 128

12 years ago
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.
OS: All → Windows XP

Comment 129

12 years ago
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
(Assignee)

Comment 130

12 years ago
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

12 years ago
> ------- 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.
(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.

> *** 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

12 years ago
*** Bug 319965 has been marked as a duplicate of this bug. ***

Comment 135

12 years ago
*** Bug 138933 has been marked as a duplicate of this bug. ***

Comment 136

11 years ago
*** Bug 334921 has been marked as a duplicate of this bug. ***

Comment 137

10 years ago
Firefox 2.0.0.2 under OSX exhibits this problem.
Eric, this bug is for the Windows builds (see the "OS" field at the top).  see comment 132 for the OSX issue.
Whiteboard: [have patch] → OSX issues are bug 314279

Updated

10 years ago
Duplicate of this bug: 324798

Comment 140

10 years ago
An (the?) equivalent Linux bug is bug 324798

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
Duplicate of this bug: 293789

Comment 142

7 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=280661

Comment 143

4 years ago
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

4 years ago
Confirmed, here as well. FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display

Comment 145

4 years ago
Same here: FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display

Comment 146

4 years ago
Should this be filed as a new bug you think? Since this one is closed and might not get any attention anymore?
Yes.  If there is no existing bug for the hidpi-specific issue, please file one.
Retina issues with multiple monitors are being tracked in bug 828514.
You need to log in before you can comment on or make changes to this bug.