In a dual monitor system, the pop up windows are split between the two screens. This is really annoying and probably relatively easy to fix. My screen size is known to windows NT as 2048 x 768. Give the user the option to set the display geometry and what part to use.

Reporter: Do you mean bug 78155or bug 95809 ? Please should also http://www.mozilla.org/quality/bug-writing-guidelines.html and use http://www.mozilla.org/quality/help/bug-form.html to report bugs. What build are you using ? Which Graphic card do you use........

-> XP Apps

BuildID: 2001080110 Windows NT 4.0 FP 3 (I think it is 3) Reproducable: Yes on this system. Video: Matrox Millennium dual cards. Matrox drivers. No - we do not try to grab the popups and fire them onto the center of screen 0 because this screws up other things. IMHO this is a relatively +easy fix (hopefully it is) but it is also a nuisance issue. The biggest problem is the pop ups for blocked ad servers. re: bug 78155. I have just tested this and the pop up can be drug properly over both screens. re: bug 95809. I see no evidence of this problem. I _never_ disable the screens anyway. I'm running dual millennium I cards I think - I'm almost certain they are not millennium II's.

I believe popups should be tied to the window that generates them. Instead of placing them in the middle of the screen - can they be placed in the middle of the generating window? This solves the problem nicely. The beautiful "mozilla" logo that opens when the program fist starts should be placed in the middle of the window that is going to open. Hopefully this information can be retained and read in first. Mozilla does remember where the main window shall be placed and the size.

I'm seeing a similar, but not exact, problem. System: Windows 2000 SP 2 Moz 0.9.4 2 video card: Matrox Millennium G200 and Velocity 128 Using the internal Windows 2000 multi-head support. Configured with the primary display on the left and the secondary display on the right. Problem: When a new window is created from a Mozilla window in the secondary display (the one on the right), the new window is created with the upper-left corner of the window only about 16 pixels from the right edge of the primary display. The window is completely functional on both displays but is neither centered in the primary display, secondary display, or evenly between the two. Recreate: 1) Have a W2k system with 2 video cards configured similarly to those listed in the system details above. 2) Start Mozilla 3) Move the window completely to the primary display and close it. 4) Start Mozilla again and note the window correctly appears on the primary display as is expected. 5) Move the window completely to the secondary display and close it. 6) Start Mozilla again and notice the window is mostly on the secondary display, but with about 16 pixels still on the right edge of the primary display.

*** Bug 101035 has been marked as a duplicate of this bug. ***

As this bug has a dupe (bug 101035), marking NEW. Related to bug 96034?

->danm

My lack of a dual monitor setup isn't helping me solve this. Anybody feel like providing a patch? I'm going to hope that bug 113283 will fix this; it centers popup windows over the parent window instead of globally.

*** Bug 150938 has been marked as a duplicate of this bug. ***

*** Bug 133854 has been marked as a duplicate of this bug. ***

*** Bug 164603 has been marked as a duplicate of this bug. ***

*** Bug 191832 has been marked as a duplicate of this bug. ***

*** Bug 173508 has been marked as a duplicate of this bug. ***

*** Bug 215373 has been marked as a duplicate of this bug. ***

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

I will take the QA for this bug for some time, since I have some ideas that about how to fix this. I will try to explain. Apparently, on dual monitor systems, one monitor has negative coordinates (at least on Windows, no idea about other OSes). If coordinates are only accepted if >=0, issue like this is going to occur. Anyone has any clue about this?

Vedran: see the screenshot attached to duplicate bug 215373. The secondary monitor is in positive coordinate space, and the popup menu is pinned to the main monitor. I think the problem is not as simple as an inability to handle a position < 0. (Note: duplicate bug 173508 comment 1 seems to claim just the opposite. But I'm not certain what the author of that comment means by the word "or.") Still, pictures don't lie, do they? Is anyone with multiple monitors still monitoring this old bug? Care to try something? I suspect that the menus are forever constrained to the monitor on which they first appear, or rather the monitor on which the owning document first appeared. Try this: 1) Launch mozilla. The first browser window should be completely within the boundaries of one monitor (bug 162090). If for some reason it isn't, resize and move it so it is, quit and relaunch (just to be safe). Either monitor will do. Let's call this monitor A. It can be your primary or secondary. 2) Click on any menu in the menubar. The "Tools" menu, say. Does it open where it should? On monitor A? 3) Move the browser window onto monitor B. Make sure it's entirely on monitor B; no part hanging over on monitor A. 4) Click the Tools menu. Does it open on monitor A? If I'm right, just for fun, try it the other way. 5) Open a second browser window. It should appear entirely on the same monitor as the first browser, which is now monitor B. Make sure it fits completely, just to be safe. 6) Click the Tools menu. Does it open on monitor B? 7) Move the second window back to monitor A. 8) Click the Tools menu. Does it open on monitor B? I suspect this because, eyeballing the code I think I see that menus are constrained to fit entirely on one monitor (in nsMenuPopupFrame::SyncViewWithFrame) and that code is multi-monitor-aware. Coordinates for the monitor it uses come from a DOMScreen held by the DOMWindow of the menu's parent document. The DOMScreen is fetched once and cached; it's never updated if the window moves. This is probably OK because the implementation of DOMScreen makes it really just a pass-through to its docshell's docviewer's prescontext's (sigh) devicecontext. However that object, also, appears to be initialized only once and never updated. That sucks because that implies that a window carries all the characteristics of its original monitor with it when moved, which should affect additional things like image rendering bit depth. Making either the DOMWindow or the prescontext take notice when the window is moved and possibly refresh the screen or devicecontext object is going to be tricky, I think. So I won't bother even trying a patch unless that's really the cause of the problem.

Ok, lets see if I (a multi-monitor user) can elaborate some on the behaviour of Moz 1.4 with regard to this and bugs marked "duplicate". This is tested on a Windows 2000 system with 3 monitors laid out in a horizontal line in order: 2 1 3 (don't ask, long story). I'll refer to this layout in the following discussion. * Menu Behaviour (bug 173508 and clarification of bug 98830 comment #18) Menus are drawn on the screen where what appears to be 51% or more of the horizontal window size is located. Meaning if most of the window is on screen 1 and then menus appear as expected on screen 1. If most of the window appears on screen 3 (the screen to the right of screen 1) then the menus appear totally on screen 3. While this can be odd looking, it is perfectly useable (I'll attach a screenshot after posting this comment). * Initial Window Placement (my own bug 98830 comment #3 below) Windows placement on my multimonitor system is working as expected. If I close Moz on one screen and start it back up, it appears on the screen I closed it down on - just as I would expect. * View Page Info/View Page Source placement (Bug 214532) This defect is in 1.4 but I have some information that might help clarify it. (Note that the original defect was filed against 1.5b.) It seems as though the View Page Info and the View Source windows remember what screen they are on much as new windows do. Hence if you open a View Page Info dialog from a given Moz window, move it to a different screen, close it, and request the same View Page Info dialog from the same Moz session, it will appear on the same screen where you closed it. Ditto for the View Page Source window. These dialogs should probably appear on the screen where the requesting window resides rather than the screen they were last closed since in some respects they are "attached" conceptually to the originating window. I'd be happy to test/confirm other dual-monitor issues on 1.4 or more recent builds if needed.

I drew red lines on the screenshot to make it easier to see where one screen ends and the other one begins. Yes, there are three screens on this system. See the first bullet of comment #19 for more details on the screenshot.

I can confirm what Casey sees. Everything to me seems like it works as I'd expect it to. The menu on another screen thing when the menubutton is on screen one, but more than 50% of the window is on screen 2 is annoying, but I never keep windows like that, so I can deal with it.

Well shoot. I thought I was on to something in comment 18. The more recent duplicate bugs seemed to confirm my suspicions. But Casey and Jason are saying there is no bug. (From comment 19 point 1 is kind of unfortunate and arguably a minor bug, though not what I thought this bug was about. Point 2 is as expected. Point 3 is an enhancement request with its own bug.) So all is well? Yet I'm afraid to close the bug because it's collected so many duplicates. The most recent of which, the one with the nice picture, was filed this month. That leaves me with (a) no way to work on this bug anyway and (b) confused about what the problem is in the first place.

*** Bug 210055 has been marked as a duplicate of this bug. ***

I saw this bug on Windows XP Pro SP1 with ATI Mobility Radeon 7500. I used windows update to get a new video card driver and the problem seems to have gone away.

*** Bug 220389 has been marked as a duplicate of this bug. ***

*** Bug 230666 has been marked as a duplicate of this bug. ***

*** Bug 230674 has been marked as a duplicate of this bug. ***

*** Bug 231803 has been marked as a duplicate of this bug. ***

*** Bug 232527 has been marked as a duplicate of this bug. ***

*** Bug 238163 has been marked as a duplicate of this bug. ***

Because of duping bug 238163 Hardware, OS -> ALL

Marking as duplicate of bug 135079 (instead of the other way around) because I feel that the other bug report is more useful to developers. *** This bug has been marked as a duplicate of 135079 ***

verified

What the hell does this bug have to do with bug 135079? Their descriptions are completely different. Duped and verified, sheesh. Nice job, guys.

This is probably a relatively simple bug to fix. But since I don't have access to a dual monitor system, it wants a new owner.

*** Bug 252440 has been marked as a duplicate of this bug. ***

in firefox 0.9 this is still a problem. i have identified that if the whole window is on a single monitor (one or the other) the menu placement is fine! However as soon as approx half of the window is on the second monitor, the menu goes wrong as shown in the attachment. Btw I've switched comupters since I erported something similar and now have MOBILITY RADEON 75000 video card.

This is also a problem on multi-headed OS X machines in Firefox 0.9.1. In particular, URL completion popups are completely botched. Don't tell me a single Moz developer doesn't have more than one display!

Not sure if it is related to this bug or a different bug. My computer is an IBM Thinkpad T41. I get the same problem with Firefox 0.9.2 if I do the following 1. Turn the laptop on without any monitor 2. Startup firefox. 3. Connect 2nd monitor 4. Enable 2nd monitor using the windows display properties 5. Move Firefox (entirely) to 2ndry monitor When I access the menu options, the menu will display on the primary monitor only. These behavour sounds slightly different to this bug. Should I submit a seperate bug report for it?

I'm pretty sure there is a bug in the window placement code for menus. A menu is constrained to fit on the screen to which its parent window belongs, and I'm pretty sure the screen to which a window belongs is cached when the window is created, and never checked again. That would describe comment 39 and bug 252440 quite nicely. Now I don't have a multiple monitor system, so I can't verify that this patch helps. And actually I suspect it's not a good patch; that it might be a performance hit. But it's certainly worth an experimental build by someone with multiple monitors.

*** Bug 158914 has been marked as a duplicate of this bug. ***

*** Bug 242858 has been marked as a duplicate of this bug. ***

*** Bug 258254 has been marked as a duplicate of this bug. ***

*** Bug 262424 has been marked as a duplicate of this bug. ***

*** Bug 264213 has been marked as a duplicate of this bug. ***

(In reply to comment #45) > *** Bug 264213 has been marked as a duplicate of this bug. *** I've just downloaded and set up tp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/beast-trunk/Firefox-win32.zip 6053 KB - 14.10.04 - 07:04:00 The ID is Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041013 Firefox/0.9.1+ The behavior I observed and reported yesterday in ex-bug 264213 has been resolved in this tinderbox.

This is still a problem in Firefox 1.0PR: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

I have this issue on OS X using a powerbook G3 with dual monitors as well. If I attach a second monitor to the computer while Firefox is running, then move the firefox window to the second monitor, right-click context windows still show up in the main monitor, until I totally close down Firefox and restart.

illustrates the context window opening up in the wrong monitor on a Powerbook G4.

(In reply to comment #48) > I have this issue on OS X using a powerbook G3 with dual monitors as well. If I > attach a second monitor to the computer while Firefox is running, then move the > firefox window to the second monitor, right-click context windows still show up > in the main monitor, until I totally close down Firefox and restart. sorry, i meant powerbook G4, and version info is: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

*** Bug 269115 has been marked as a duplicate of this bug. ***

*** Bug 269935 has been marked as a duplicate of this bug. ***

*** Bug 272564 has been marked as a duplicate of this bug. ***

corresponding Firefox bug is Bug 245418 (with patch for the same file)

The same work is being done in this bug and bug 245418. I recommend it be duped to this one, but will hold off on that change for now. They both have a large number of dupes, but bug 245418 seems to be more active than this one, with it's patch already having review.

*** This bug has been marked as a duplicate of 245418 ***

The other one has review, so I guess I'll verify. It would still be a good idea for someone (DanM?) to take a look at the other approach and how it compares to this one.