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)
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)
88.82 KB,
image/png
|
Details | |
6.65 KB,
patch
|
mikepinkerton
:
review+
roc
:
superreview+
asa
:
approval1.8rc1+
|
Details | Diff | Splinter Review |
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•20 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•20 years ago
|
||
*** Bug 251927 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•20 years ago
|
||
*** Bug 254882 has been marked as a duplicate of this bug. ***
Comment 4•20 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•20 years ago
|
Flags: blocking-aviary1.0mac?
Comment 5•20 years ago
|
||
Use the right screen to reposition a nsMenuPopupFrame.
Comment 6•20 years ago
|
||
peterv: were you able to actually test this patch on multiple monitors?
Comment 7•20 years ago
|
||
Yes, but if anyone else can test them too it'd be good to have confirmation that it works elsewhere. ;-)
Comment 8•20 years ago
|
||
Comment on attachment 160941 [details] [diff] [review] v1 Looks good.
Attachment #160941 -
Flags: review+
Updated•20 years ago
|
Attachment #160941 -
Flags: superreview?(bryner)
Comment 9•20 years ago
|
||
*** Bug 138905 has been marked as a duplicate of this bug. ***
Comment 10•20 years ago
|
||
*** Bug 266798 has been marked as a duplicate of this bug. ***
Comment 11•20 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
Updated•20 years ago
|
Whiteboard: [have patch]
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Updated•20 years ago
|
Blocks: multimon-win
Comment 12•20 years ago
|
||
Got the same problem.
Comment 13•20 years ago
|
||
*** Bug 269509 has been marked as a duplicate of this bug. ***
Comment 14•20 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•20 years ago
|
||
*** Bug 271273 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
Two dupes are PC/Win32, so Hardware/OS should be changed to All/All. And the summary needs an update too.
Comment 17•20 years ago
|
||
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•20 years ago
|
||
*** 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
Comment 19•20 years ago
|
||
*** Bug 260448 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
corresponding Seamonkey bug is Bug 98830 (with patch for the same file)
Updated•20 years ago
|
Alias: ContextMenuScreen
Comment 21•20 years ago
|
||
*** Bug 255551 has been marked as a duplicate of this bug. ***
Comment 22•20 years ago
|
||
*** Bug 273192 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.0- → blocking-aviary1.0+
Updated•20 years ago
|
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Comment 23•20 years ago
|
||
zac@zacbowling.com, please don't touch the blocking flags.
Flags: blocking-aviary1.0-
Comment 24•20 years ago
|
||
Happens in Linux all flavors using dual head or single head /w Nvidia TwinView drivers as well.
Comment 25•20 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•20 years ago
|
||
*** Bug 273832 has been marked as a duplicate of this bug. ***
Comment 27•20 years ago
|
||
*** Bug 274883 has been marked as a duplicate of this bug. ***
Comment 28•20 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/
Comment 29•20 years ago
|
||
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 30•20 years ago
|
||
Comment on attachment 160941 [details] [diff] [review] v1 restoring r= from javeier
Attachment #160941 -
Flags: review+
Comment 31•20 years ago
|
||
*** Bug 275399 has been marked as a duplicate of this bug. ***
Comment 32•20 years ago
|
||
*** Bug 275395 has been marked as a duplicate of this bug. ***
Comment 33•20 years ago
|
||
*** Bug 275755 has been marked as a duplicate of this bug. ***
Comment 34•20 years ago
|
||
*** Bug 98830 has been marked as a duplicate of this bug. ***
Comment 35•20 years ago
|
||
*** Bug 277286 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: firefox → nobody
QA Contact: bugzilla
Updated•20 years ago
|
Assignee: nobody → peterv
Flags: blocking-aviary1.1?
Comment 36•20 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•20 years ago
|
||
*** Bug 277773 has been marked as a duplicate of this bug. ***
Comment 38•20 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.
Comment 39•20 years ago
|
||
*** Bug 277824 has been marked as a duplicate of this bug. ***
Comment 40•20 years ago
|
||
*** Bug 267120 has been marked as a duplicate of this bug. ***
Comment 41•20 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•20 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•20 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•20 years ago
|
||
*** Bug 279113 has been marked as a duplicate of this bug. ***
Comment 45•20 years ago
|
||
*** Bug 279467 has been marked as a duplicate of this bug. ***
Comment 46•19 years ago
|
||
*** Bug 214532 has been marked as a duplicate of this bug. ***
Comment 47•19 years ago
|
||
*** Bug 230065 has been marked as a duplicate of this bug. ***
Comment 48•19 years ago
|
||
*** Bug 279933 has been marked as a duplicate of this bug. ***
Comment 49•19 years ago
|
||
I wonder if this is related? http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsScreenManagerMac.cpp#118
Comment 50•19 years ago
|
||
*** Bug 280549 has been marked as a duplicate of this bug. ***
Comment 51•19 years ago
|
||
*** Bug 280853 has been marked as a duplicate of this bug. ***
Comment 52•19 years ago
|
||
*** Bug 281422 has been marked as a duplicate of this bug. ***
Comment 53•19 years ago
|
||
*** Bug 282346 has been marked as a duplicate of this bug. ***
Comment 54•19 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.
Comment 55•19 years ago
|
||
*** Bug 282852 has been marked as a duplicate of this bug. ***
Comment 56•19 years ago
|
||
*** Bug 232690 has been marked as a duplicate of this bug. ***
Comment 57•19 years ago
|
||
*** Bug 283172 has been marked as a duplicate of this bug. ***
Comment 58•19 years ago
|
||
*** Bug 283320 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
*** Bug 283544 has been marked as a duplicate of this bug. ***
Comment 60•19 years ago
|
||
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•19 years ago
|
||
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•19 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•19 years ago
|
||
*** Bug 285329 has been marked as a duplicate of this bug. ***
Comment 64•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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+
Comment 67•19 years ago
|
||
(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•19 years ago
|
||
> 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•19 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•19 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•19 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.
Comment 72•19 years ago
|
||
> 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•19 years ago
|
||
*** Bug 285638 has been marked as a duplicate of this bug. ***
Comment 74•19 years ago
|
||
*** Bug 287254 has been marked as a duplicate of this bug. ***
Comment 75•19 years ago
|
||
*** Bug 287591 has been marked as a duplicate of this bug. ***
Updated•19 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•19 years ago
|
||
*** Bug 287822 has been marked as a duplicate of this bug. ***
Comment 77•19 years ago
|
||
*** Bug 288454 has been marked as a duplicate of this bug. ***
Comment 78•19 years ago
|
||
*** Bug 288450 has been marked as a duplicate of this bug. ***
Comment 79•19 years ago
|
||
*** Bug 289533 has been marked as a duplicate of this bug. ***
Comment 80•19 years ago
|
||
*** Bug 289533 has been marked as a duplicate of this bug. ***
Comment 81•19 years ago
|
||
*** Bug 291400 has been marked as a duplicate of this bug. ***
Comment 82•19 years ago
|
||
*** Bug 292621 has been marked as a duplicate of this bug. ***
Comment 83•19 years ago
|
||
*** Bug 293013 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking1.8b3?
Updated•19 years ago
|
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
Comment 84•19 years ago
|
||
*** Bug 295135 has been marked as a duplicate of this bug. ***
Comment 85•19 years ago
|
||
*** Bug 295242 has been marked as a duplicate of this bug. ***
Comment 86•19 years ago
|
||
*** Bug 294992 has been marked as a duplicate of this bug. ***
Comment 87•19 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
Comment 88•19 years ago
|
||
> 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•19 years ago
|
||
*** Bug 297581 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking1.8b3? → blocking1.8b3-
Comment 90•19 years ago
|
||
*** Bug 298121 has been marked as a duplicate of this bug. ***
Comment 91•19 years ago
|
||
*** Bug 300378 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking1.8b4?
Comment 92•19 years ago
|
||
*** Bug 300815 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Flags: blocking-aviary2.0+
Comment 93•19 years ago
|
||
*** Bug 261148 has been marked as a duplicate of this bug. ***
Comment 94•19 years ago
|
||
*** Bug 303396 has been marked as a duplicate of this bug. ***
Comment 95•19 years ago
|
||
*** Bug 303653 has been marked as a duplicate of this bug. ***
Comment 96•19 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•19 years ago
|
||
*** Bug 304701 has been marked as a duplicate of this bug. ***
Comment 98•19 years ago
|
||
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•19 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.
Comment 100•19 years ago
|
||
possible dups?: Bug 138933 Bug 291434 patch not checked in?
Comment 101•19 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•19 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. :)
Comment 103•19 years ago
|
||
*** Bug 309238 has been marked as a duplicate of this bug. ***
Comment 104•19 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
Comment 105•19 years ago
|
||
*** Bug 309193 has been marked as a duplicate of this bug. ***
Comment 106•19 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•19 years ago
|
||
*** Bug 312628 has been marked as a duplicate of this bug. ***
Comment 108•19 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•19 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•19 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•19 years ago
|
||
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•19 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•19 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•19 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-
Comment 115•19 years ago
|
||
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•19 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+
Updated•19 years ago
|
Assignee: peterv → brettw
Comment 118•19 years ago
|
||
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•19 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•19 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•19 years ago
|
||
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Attachment #200155 -
Flags: approval1.8rc1? → approval1.8rc1+
Comment 122•19 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
Updated•19 years ago
|
Flags: blocking1.8b5-
Flags: blocking1.8b3-
Flags: blocking-aviary2.0+
Comment 123•19 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•19 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•19 years ago
|
||
*** Bug 314426 has been marked as a duplicate of this bug. ***
Comment 126•19 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
Comment 127•19 years ago
|
||
> I filed another bug AS REQUESTED.
What bug number?
Assignee | ||
Comment 128•19 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•19 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•19 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•19 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.
Comment 132•19 years ago
|
||
(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•19 years ago
|
||
> *** 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•19 years ago
|
||
*** Bug 319965 has been marked as a duplicate of this bug. ***
Comment 135•19 years ago
|
||
*** Bug 138933 has been marked as a duplicate of this bug. ***
Comment 136•18 years ago
|
||
*** Bug 334921 has been marked as a duplicate of this bug. ***
Comment 137•17 years ago
|
||
Firefox 2.0.0.2 under OSX exhibits this problem.
Comment 138•17 years ago
|
||
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
Comment 140•17 years ago
|
||
An (the?) equivalent Linux bug is bug 324798
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
Comment 142•14 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=280661
Comment 143•11 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•11 years ago
|
||
Confirmed, here as well. FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display
Comment 145•11 years ago
|
||
Same here: FF on 2nd normal monitor and all dropdowns appear in minuscule format on the retina display
Comment 146•11 years ago
|
||
Should this be filed as a new bug you think? Since this one is closed and might not get any attention anymore?
Comment 147•11 years ago
|
||
Yes. If there is no existing bug for the hidpi-specific issue, please file one.
Comment 148•11 years ago
|
||
Retina issues with multiple monitors are being tracked in bug 828514.
Comment 149•4 years ago
|
||
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)
Comment 150•4 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Keywords: regression
Comment 151•4 years ago
|
||
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.
Description
•