251994 - window size can exceed available screen real estate on launch

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Asa Dotzler [:asa]]

On Windows Firefox, if I open the browser, put the window in the restored state,
size the window to be taller than my screen, such that the statusbar is hidden
behind the Windows taskbar, and then restart the browser, the window comes up
restored to a size that fits on the visible screen. 

On OS X, if I follow the same basic steps, putting the statusbar behind the OS X
dock, and restart the browser, the window comes up still obscured by the dock. 

Given that a users who loses his statusbar and possibly his scrollbar's down
arrow isn't going to have a very nice experience using our browser, I think we
should fix this for Mac 1.0.

Additional info: Safari doesn't suffer from this problem. On restart, the window
is sized such that the bottom edge is just above the top edge of the dock.

Comment 1

[Asa Dotzler [:asa]]

This was tested with the 20040717 Mac Firefox branch build on OS X 10.3. I
believe that the 0.9.x releases also suffer from this problem. 

Comment 2

[Asa Dotzler [:asa]]

I also noticed that the initial window size on first launch is exactly the
height of the statusbar too tall and so the statusbar is obscured behind the
dock. We need to subract about 12 vertical pixels from the current computation
of avialable space on initial launch.

Comment 3

[Federico Mena-Quintero]

This is related to bug #232920.

I live in X11/Gtk2, so the following will not be very useful on other platforms,
I'm afraid :)

On Gtk2, and on screens larger than 640x480, we semi-hardcode a default size
around mozilla/browser/base/content/browser.js:1100:

   defaultHeight = screen.availHeight - 10;
   ...
   document.documentElement.setAttribute("height", defaultHeight);

In the Gtk2 implementation, the screen.availWidth/Height correspond to the
NET_WM_WORKAREA from the window manager.  However, the code above doesn't take
into account the size of the window manager's window frame.

As of 2004/09/16, the Window Manager Specification doesn't specify a standard
way of getting the size of the window frame on each edge of the window
(http://www.freedesktop.org/Standards/wm-spec).  Newer drafts probably have this
in mind.

For now, I think we could add some stuff to the Window classes to
maximize_vertically.  In X11/Gtk2, this amounts to setting
NET_WM_STATE_MAXIMIZED_VERT/NET_WM_STATE.

Comment 4

[Brian Ryner (not reading)]

I'm thinking for 1.0 we may just want to hack it to allow 20 or 25px.  I'm not
sure we want it vertically maximized (hence the subtracting 10)... leaving a
little bit of space on the bottom makes it easy for the user to grab the window
frame to resize it.

(In reply to comment #3)
> This is related to bug #232920.
> 
> I live in X11/Gtk2, so the following will not be very useful on other platforms,
> I'm afraid :)
> 
> On Gtk2, and on screens larger than 640x480, we semi-hardcode a default size
> around mozilla/browser/base/content/browser.js:1100:
> 
>    defaultHeight = screen.availHeight - 10;
>    ...
>    document.documentElement.setAttribute("height", defaultHeight);
> 
> In the Gtk2 implementation, the screen.availWidth/Height correspond to the
> NET_WM_WORKAREA from the window manager.  However, the code above doesn't take
> into account the size of the window manager's window frame.
> 
> As of 2004/09/16, the Window Manager Specification doesn't specify a standard
> way of getting the size of the window frame on each edge of the window
> (http://www.freedesktop.org/Standards/wm-spec).  Newer drafts probably have this
> in mind.
> 
> For now, I think we could add some stuff to the Window classes to
> maximize_vertically.  In X11/Gtk2, this amounts to setting
> NET_WM_STATE_MAXIMIZED_VERT/NET_WM_STATE.

Comment 5

[Brian Ryner (not reading)]

Attachment: patch

I got 28px by looking at Meta

Comment 6

[Brian Ryner (not reading)]

Attachment: patch

I got 28px by looking at Metacity/ Bluecurve, and I think it's pretty standard
size-wise.

Comment 7

[Mike Shaver (:shaver emeritus)]

Comment on attachment 159774 [details] [diff] [review]
patch

Looks good to me. r=shaver

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 159774 [details] [diff] [review]
patch

a=[e-mail]

Comment 9

[Brian Ryner (not reading)]

checked in on trunk and aviary branch.

Comment 10

[Bowman and Company]

Thanks for solving my question too. I had doubt on the same topic. U have been cleared doubt for me.Keep on answering some fabulos questions.
Foolow us: http://www.bowmanandcompany.com.au/