User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 I have a dual monitor system, with two separate (and different) graphics adaptors. The monitors are configured as follows: Desktop Width: 2624 Height: 1200 Left: -1600 Top: -432 Monitor 1 (Primary) Width: 1024 Height: 768 Left: 0 Top: 0 Workspace Width: 1024 Height: 734 Left: 0 Top: 0 Monitor 2 Width: 1600 Height: 1200 Left: -1600 Top: -432 Workspace Width: 1600 Height: 1200 Left: -1600 Top: -432 That is, the secondary monitor is located to the left of the primary monitor, with the bottoms aligned. The taskbar is at the bottom of the primary monitor. If I close FireFox with the following settings: Width: 1206 Height: 1126 Top: -433 Left: -1468 That is, the window is on the non-primary monitor to the left of the primary monitor. I then restart the browser and the main windows is displayed as follows: Width: 1024 Height: 734 Top: -433 Left: -1468 That is, the window has the correct top and left position (on the secondary monitor) but has been resized (shrunk) according to the available workspace on the PRIMARY monitor. Reproducible: Always Steps to Reproduce: 1. Start the browser and position the main window on the secondary monitor 2. Increase the size of the main window beyond the size of the PRIMARY monitor workspace 3. Close the browser 4. Restart the browser Actual Results: The main window has been shrunk to the size of the PRIMARY monitor workspace, despite there being ample space on the secondary monitor where the main window is shown. Expected Results: The main window should determine which monitor it is being displayed on (using the EnumDisplayMonitors system call) and resize according to the available space on that monitor. Primary graphics adaptor: NeoMagic MagicGraph256ZX Secondary graphics adaptor: NVIDIA GeForce2 MX/MX 400
A similar situation occurs on Mac OS X; my setup is a PowerBook with an external monitor. The secondary is aligned at the top with the primary, and is taller. When a new window is opened on the secondary, it is sized so that it would fit on the primary.
I have now changed PCs and can confirm that this bug also affects dual displays running from a single graphics card. I'm using an HP-Compaq nx7010 notebook, with ATi Mobility Radeon 9200. The main display is 1280x800, while the external display is 1600x1200. If I shutdown Firefox while being displayed with a window of 1500x1100, on restart the window will be resized to 1280x800. BTW, is there anything I can do to progress the resolution of this bug?
I can confirm this bug in Linux. It occurs with nvidia's TwinView is configured with my monitor and television. Section "Device" Identifier "twin" Driver "nvidia" Option "TwinView" Option "TwinViewOrientation" "Clone" Option "SecondMonitorHorizSync" "30-50" Option "SecondMonitorVertRefresh" "60" Option "MetaModes" "1600x1200,800x600; 800x600,800x600" Option "ConnectedMonitor" "CRT, TV" Option "TVStandard" "NTSC-M" EndSection I had this problem originally in Firefox 1.0PR, but not on any official release prior to that. Versions 1.0 - 1.0.4 have been fine, as well as Deer Park Alpha 1 and 2. I haven't tried 1.0.5, but the problem has resurfaced in 1.0.6. I was hoping there would be an option in about:config to disable restricting the window size to the resolution, but no such luck. The funny thing is, firefox will let me resize it all the way to my actual screen resolution without problems, the wrong restriction is only applied at startup.
(In reply to comment #3) > I had this problem originally in Firefox 1.0PR, but not on any official release > prior to that. Versions 1.0 - 1.0.4 have been fine, as well as Deer Park Alpha 1 > and 2. I haven't tried 1.0.5, but the problem has resurfaced in 1.0.6. :) my appologies. my linux distribution has been experimenting with some patches for the release of firefox 1.0.6. this bug does NOT occur in the official mozilla build. i'll have to discuss this with them and determine which patch did it! sorry, once again!
Well, I was wrong again. It wasn't a patch causing this problem. Turns out enabling Xinerama support triggers this bug.
Based on the comments, this doesn't look like a Mozilla bug. If that is so, please resolve it as INVALID using the options above.
For me, this problem only affects Firefox and Thunderbird applications. In addition, it occurs on multiple PCs with significantly different hardware configurations. I can only assume that it's a bug from some common library or widget set that's shared between these Mozilla applications. If I don't list it as a bug here, I'm not sure where it should go. Any suggestions? (In reply to comment #6) > Based on the comments, this doesn't look like a Mozilla bug. If that is so, > please resolve it as INVALID using the options above.
Having upgraded to Firefox 1.5, I can confirm that the behaviour remains the same. That is, the window continues to be shrunk according to the size of the primary monitor, even if the secondary monitor is large enough to accomodate the original window.
Similar to Bug 368023
Confirming this and based on the comments all platforms (I see it on OSX).
The cause of this is fairly simple. When creating a new XUL window it is initially positioned on the primary monitor. Then the persisted size is restored and constrained to the monitor size. Then the persisted position is restored (thus moving it to the alternate monitor). Unfortunately it's not quite as simple as reversing the order of restoration, we actually need the size of the window in order to work out the target position correctly. I have an idea of how to solve this though.
Created attachment 296342 [details] [diff] [review] patch rev 1 When working out the size of the window take into account any screenX/screenY attributes that might move us to a different screen and use that new screen to constrain the size instead.
Comment on attachment 296342 [details] [diff] [review] patch rev 1 Uhh no actually that's broken.
Wow, this bug was first reported in 2005? And here, I thought I'd be the first one to report it! Anyway, confirming it is still a problem on Windows 7 64-bit, with Firefox 3.6.13. Mostly I've been running Firefox on the main monitor, but just developed a reason to run a second profile version of Firefox on the secondary monitor, and discovered this bug. The window can be stretched after creation, but that is annoying to have to do.
Interesting that after a Windows crash, Firefox can restore the session, including the screen size, but that it puts this size restriction on creating new windows for new sessions! So it seems the right code exists in Firefox, but the wrong code is being used at new session startup.
fwiw, this bug affects me even when starting firefox on the primary monitor, and the secondary monitor is smaller. can someone provide some hints about where in the code this restriction is made so i can at least hack it out for myself, since my wm will not allow windows larger than the screen to map anyway?
Well, found it, it's in nsXULWindow::LoadSizeFromXUL(), in xpfe/appshell/src/nsXULWindow.cpp. Just remove everything after the "// constrain to screen size" comment. I also found some similar code in nsWindowWatcher::SizeOpenedDocShellItem() but it seems to not apply in this case.
Still a Problem in Firefox and Thunderbird 11. Very annoying, because in gnome-shell the window size is not directly getting changed, but gnome goes to overview-mode and after clicking firefox window it moves to my smaller secondary screen, again in overview mode. So it takes me at least three clicks (with a lot jumping windows) after starting firefox before i can actually use it. Why is this window resizing even necessary? Shouldn't this be the window-managers task? Reproducibility: happens when the window size when closing firefox was greater than the size of my smaller (secondary, left) screen.