Closed Bug 245418 (ContextMenuScreen) Opened 20 years ago Closed 19 years ago

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

Categories

(Core :: XUL, defect)

All
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mark, Assigned: brettw, NeedInfo)

References

Details

(Keywords: fixed1.8, polish, regression, Whiteboard: OSX issues are bug 314279)

Attachments

(2 files, 1 obsolete file)

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
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.
*** 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. ***
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).
Flags: blocking-aviary1.0mac?
Attached patch v1 (obsolete) — Splinter Review
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)
*** Bug 138905 has been marked as a duplicate of this bug. ***
*** Bug 266798 has been marked as a duplicate of this bug. ***
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-
Blocks: multimon-win
Got the same problem.
*** Bug 269509 has been marked as a duplicate of this bug. ***
(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.
*** Bug 271273 has been marked as a duplicate of this bug. ***
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
*** Bug 271522 has been marked as a duplicate of this bug. ***
Summary: contextual menus open on wrong screen when using two screens → menus and contextual menus open on wrong screen when using two screens
*** Bug 260448 has been marked as a duplicate of this bug. ***
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. ***
*** Bug 273192 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0- → blocking-aviary1.0+
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
zac@zacbowling.com, please don't touch the blocking flags.
Flags: blocking-aviary1.0-
Happens in Linux all flavors using dual head or single head /w Nvidia TwinView
drivers as well.
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). 
*** Bug 273832 has been marked as a duplicate of this bug. ***
*** Bug 274883 has been marked as a duplicate of this bug. ***
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. ***
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?
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
*** Bug 277773 has been marked as a duplicate of this bug. ***
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. ***
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.
(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
(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.
*** Bug 279113 has been marked as a duplicate of this bug. ***
*** Bug 279467 has been marked as a duplicate of this bug. ***
*** Bug 214532 has been marked as a duplicate of this bug. ***
*** Bug 230065 has been marked as a duplicate of this bug. ***
*** Bug 279933 has been marked as a duplicate of this bug. ***
*** Bug 280549 has been marked as a duplicate of this bug. ***
*** Bug 280853 has been marked as a duplicate of this bug. ***
*** Bug 281422 has been marked as a duplicate of this bug. ***
*** Bug 282346 has been marked as a duplicate of this bug. ***
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. ***
*** Bug 232690 has been marked as a duplicate of this bug. ***
*** Bug 283172 has been marked as a duplicate of this bug. ***
*** Bug 283320 has been marked as a duplicate of this bug. ***
*** Bug 283544 has been marked as a duplicate of this bug. ***
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)
Also affect Intel GMA900 Graphics on my machine.

The menues etc appear on the primary monitor instead of the correct one.
*** 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....
(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....

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.
(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....
*** Bug 285638 has been marked as a duplicate of this bug. ***
Blocks: 280625
*** Bug 287254 has been marked as a duplicate of this bug. ***
*** Bug 287591 has been marked as a duplicate of this bug. ***
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
*** Bug 287822 has been marked as a duplicate of this bug. ***
*** Bug 288454 has been marked as a duplicate of this bug. ***
*** 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. ***
*** 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. ***
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. ***
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 294992 has been marked as a duplicate of this bug. ***
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".
*** Bug 297581 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b3? → blocking1.8b3-
*** Bug 298121 has been marked as a duplicate of this bug. ***
Blocks: 282051
*** Bug 300378 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking1.8b4?
*** Bug 300815 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Flags: blocking-aviary2.0+
Blocks: 295540
*** Bug 261148 has been marked as a duplicate of this bug. ***
*** Bug 303396 has been marked as a duplicate of this bug. ***
*** Bug 303653 has been marked as a duplicate of this bug. ***
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.
*** 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.
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?
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
(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. ***
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. ***
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.
*** Bug 312628 has been marked as a duplicate of this bug. ***
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?
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.
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 :-)
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 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 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)
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.
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+
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 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?
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #200155 - Flags: approval1.8rc1? → approval1.8rc1+
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+
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.
> 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. 
*** Bug 314426 has been marked as a duplicate of this bug. ***
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?
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
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
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 #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.
*** Bug 319965 has been marked as a duplicate of this bug. ***
*** Bug 138933 has been marked as a duplicate of this bug. ***
*** Bug 334921 has been marked as a duplicate of this bug. ***
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
An (the?) equivalent Linux bug is bug 324798
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
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
Confirmed, here as well. FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display
Same here: FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display
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.

This is same bug is currently happening for me - macOS 10.15.2 / Firefox 72.0.2

I have three external displays attached to a 2017 Macbook Pro.

Video: https://drive.google.com/open?id=1BvfgrgvKZONDeCUcQ5URT3sDUzOpayuh

Flags: needinfo?(brettw)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

I'm having this problem on macOS 1.15.3. Please reopen. If Firefox is on my second monitor, right-clicking something will make the menu pop up in the wrong place on the second monitor, somewhere on the primary monitor, or not at all. This problem didn't occur in earlier versions of macOS.

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

Attachment

General

Created:
Updated:
Size: