396379 - Multiple Monitors: new window size constrained to size of main (primary, menu bar) window

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[Jeremy]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.7pre) Gecko/20070903 SeaMonkey/1.1.5pre

Terminology:  Mac calls it the Menu Bar Screen, Windows calls the Primary Monitor, I'm calling it the main screen.

In a 2-monitor setup where the main screen is smaller than the other screen, new windows are constrained to be no larger than the size of the main screen.

This has been reproduced on Mac OS X 10.3.9 and Windows XP Pro SP2 with Firefox 2.0.0.6 and I believe it to be an old bug.

Reproducible: Always

Steps to Reproduce:
1. Set up two monitors of significantly different sizes (pixel height and width).
2. Make the smaller monitor the main screen (had Menu Bar on Mac, has Task Bar on Windows).
3. Start Firefox/SeaMonkey.
4. Manually resize the window to noticeably larger than the main screen.
5. Select "New Window" from the File menu.
Actual Results:  
The new window is the size of the main screen.

Expected Results:  
The new window is the size of the old window.

Just a guess, but this might be due to someone calling gdk_screen_width() and gdk_screen_height() to constrain the size instead of getting the size constraint from the correct screen object.

See mozilla/ widget/ src/ windows/ nsWindow.cpp ConstrainPosition() as an example of how to lookup the screen manager and ask the screen manager to give you the screen the window is targeted to be on and then getting the size constraints from that screen object.

BTW, mozilla/ widget/ src/ gtk2/ nsWindow.cpp seems to incorrectly constrain the window to be on the main screen in ConstrainPosition via the same kind of mistake.

This is probably due to the same underlying cause of Bug 394843.

Comment 1

[Dave Townsend [:mossop]]

I believe that this is probably the same issue as bug 251024

Comment 2

[Jeremy]

The difference between this bug and bug 251024 is that this bug affects new windows in a running program, not windows restored from persistent state.  In the latter, there is an externally supplied target size and position, while in the former it is the internal window positioning and sizing code that is determining the target size and placement of the window.  Whether that is a significant distinction in terms of fixing the problem I don't know.  It strikes me as plausible that one could solve this bug without solving bug 251024.