251024 - On startup the main window is incorrectly sized according to the workspace of the primary monitor

Status: NEW

(Core :: Widget, defect)

Description

[Bruce J Clark]

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

Comment 1

[Guillaume Lessard]

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.

Comment 2

[Bruce J Clark]

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?

Comment 3

[Paul Seropian]

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.

Comment 4

[Paul Seropian]

(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!

Comment 5

[Paul Seropian]

Well, I was wrong again. It wasn't a patch causing this problem.

Turns out enabling Xinerama support triggers this bug.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 7

[Bruce J Clark]

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.

Comment 8

[Bruce J Clark]

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.

Comment 9

[Jeremy]

Similar to Bug 368023 

Comment 10

[Dave Townsend [:mossop]]

Confirming this and based on the comments all platforms (I see it on OSX).

Comment 11

[Dave Townsend [:mossop]]

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.

Comment 12

[Dave Townsend [:mossop]]

Attachment: 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 13

[Dave Townsend [:mossop]]

Comment on attachment 296342 [details] [diff] [review]
patch rev 1

Uhh no actually that's broken.

Comment 15

[Glenn Linderman]

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.

Comment 16

[Glenn Linderman]

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.

Comment 17

[Mikael Magnusson]

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?

Comment 18

[Mikael Magnusson]

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.

Comment 19

[h.vorwerk]

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.

Comment 20

[ricdan]

I can reproduce what appears to be the same underlying issue in Thunderbird 156.0 on Windows 11 with two identical 1920×1080 monitors at 100% scaling.

The Thunderbird main window is intentionally configured to span both monitors. The desired geometry is approximately:

screenX = -9
screenY = 0
width = 3846
height = 1032
sizemode = normal

Thunderbird correctly persists this geometry in:

xulstore.json
chrome://messenger/content/messenger.xhtml
messengerWindow

However, after restarting Thunderbird, the window is restored to one monitor only:

X = 0
Y = 0
Width = 1920
Height = 1032

I performed several tests to distinguish persistence problems from window-restoration problems.

Environment:

Windows 11
Thunderbird 156.0
2 × 1920×1080 displays
100% scaling on both displays
Same GPU/display setup

The issue is reproducible in Thunderbird Troubleshoot Mode with extensions disabled.

Windows "WindowArrangementActive" was disabled for testing, with no change.

PowerToys/FancyZones was completely terminated, with no change.

No third-party multi-monitor/window-management software is installed.

The important observation is that the persisted geometry itself is correct.

Before Thunderbird startup, xulstore.json contains:

screenX  = -9
screenY  = 0
width    = 3846
height   = 1032
sizemode = normal

During startup I sampled xulstore.json repeatedly at approximately 50 ms intervals. It remains unchanged at width=3846 while Thunderbird starts.

Nevertheless, once the Thunderbird top-level window exists, Win32 GetWindowPlacement() reports:

rcNormalPosition:
X      = 0
Y      = 0
Width  = 1920
Height = 1032

Therefore Thunderbird/Gecko appears to clamp the restored window geometry to one monitor during window creation/restoration even though xulstore.json still contains the correct 3846-pixel width.

I also verified that Windows itself accepts the intended geometry.

After Thunderbird has started, using Win32 MoveWindow() on the Thunderbird top-level HWND with:

X = -9
Y = 0
Width = 3846
Height = 1032

works correctly.

Immediately afterwards GetWindowRect() reports:

X      = -9
Y      = 0
Width  = 3846
Height = 1032

and the Thunderbird window correctly spans both monitors.

After closing Thunderbird normally in this state, xulstore.json correctly persists:

screenX  = -9
screenY  = 0
width    = 3846
height   = 1032
sizemode = normal

On the next startup, however, GetWindowPlacement() again reports:

X      = 0
Y      = 0
Width  = 1920
Height = 1032

Therefore this does not appear to be a persistence failure. The correct geometry is saved, but the persisted 3846-pixel width is apparently constrained to the primary monitor's approximately 1920-pixel workspace during startup.

This seems particularly consistent with the mechanism described in comment 11 of this bug: the new XUL window is initially associated with the primary monitor, the persisted size is restored and constrained to that monitor, and only afterwards is the persisted position considered.

I also tested these preferences with no change:

browser.startup.preXulSkeletonUI = false
browser.startup.blankWindow = false

A very old Thunderbird-specific report also appears to describe the same user-visible symptom:

Bug 267106 — Thunderbird window doesn't properly remember position when spanning multiple displays.

The behavior therefore appears to still be reproducible in Thunderbird 156.0 / Windows 11.

Please let me know if additional diagnostics, a reduced profile, Win32 geometry logs, or testing with Thunderbird Beta/Daily would be useful.