197410 - Residual state from dual headed monitor sessions can cause size problems without second head

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[Mike Neff]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212

I normally have my Powerbook connected to my larger resolution 21" monitor head
which is where my main head is set to on my two headed system.  When launching
Mozilla it creates a window sized to fit within the larger resolution setup,
since it remembers the previously closed Mozilla window for sizing info.  If I
bring up my Powerbook separately from my dual headed setup and try to start
Mozilla, one of two things happens with the windows that are created, which
doesn't appear to be correctable (without going back to my two-headed setup).  

1.  The window allows one to have access to the top window controls, but the
bottom of the window is below the fold of the screen, not allowing it to be
resized, since one cannot get one's mouse over the bottom resize corner.

2.  For windows that are launched from other apps like mail or even from within
browser sessions, other browser windows come up with the top window controls
above the fold and inaccessable, making it impossible to kill or move the window
without killing Mozilla completely and restarting it.



Reproducible: Always

Steps to Reproduce:
1.  Start with a dual headed system with an external monitor connected to a
Macintosh system where the external monitor is of larger resolution and is used
as the main head.
2.  Use Mozilla and resize it close to the max allowed on the larger monitor
head.  End Mozilla.
3.  Disconnect second monitor head.
4.  Bring up Mac OSX with single monitor head, and try then to just start
Mozilla.  Window condition 1 will happen.
5.  To bring up window condition 2, launch a URL link from Mail.App mail with it
set default to launch Mozilla brower windows.

Actual Results:  
Step 4 will lead to window condition 1 listed above.

Step 5 will lead to window condition 2 listed above.

Expected Results:  
It seems to correct this problem, upon startup, if Mozilla detects that it's
saved window height is greater than existing head real estate space (on the
active heads), it should shorten the height to allow both top and bottom window
controls accessable to the user to avoid this problem state.

Perhaps this is a Mac OSX GUI toolkit issue as well, but it would seem to be
something that could be worked around even if it is.

Running MacOSX Jaguar version on G4 Powerbook.

Comment 1

[Bruce Davidson]

Mike, is this still a problem on recent builds? If so I'll confirm this bug (I
don't have a dual head display to test it on :-(, but its a valid bug and not
seemingly a dupe).

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.