53506 - [meta] Mac window sizing and placement, after zoom and on new window

Status: RESOLVED INCOMPLETE

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

Description

[Terence Tan]

This bug is a catch-all for Mac window sizing and placement theory, i.e. where 
windows display when you create new ones or zoom existing ones. Hopefully, this 
might make Mozilla adhere a bit closer to Apple's standards. Bear with me, I'm 
going to go into some freeform thinking here. (Part of the reason I'm doing this 
is because IE5 for Mac doesn't do it quite right either.)

I'm not sure about the cross-platform rules... maybe the behaviour is 
deliberately set like this to standardise across platforms. (Tell me if that's 
the case, so I don't make more of a fool of myself...)

In Mac OS, there are two states a window can be in: standard state, and user 
state. Standard state is whatever the application thinks is a convenient default 
for the user. In our case, it's the full screen. The user state is whatever the 
user has resized to. Clicking the zoom box will toggle between the two states. 
Resizing the window with the grow box will set the user state.

---

How Mozilla Currently Does It:

* Standard state: window covers most of screen, except a thin line across the top 
(using Platinum theme) and a thicker strip down the right side.

* User state: whatever the user last resized to.

* Opening a new window: sets window position to the user state.

---

How Netscape 4.x Does It:

* Standard state: window uses 'smart sizing' (ref: bug 13179).

* User state: whatever the user last resized to, or the size of the last zoom.

* Opening a new window: sets window position to the user state, or, if there is a 
window already at this user state, sets window position to the user state plus an 
offset (moved right and down).

* Closing a window: sets user state according to position of closing window 
(whether it's in standard or user state). So windows will open in the exact size 
you last closed them.

* Option-zoom: zooms window to the maximum possible size and sets user state to 
this size.

---

How Mozilla Should (In My Humble Opinion) Do It:

* Standard state: window covers all of screen, except a three-pixel margin on all 
sides. (The patch to do this is fairly trivial: comment out the 
SetWindowStandardState call, line 691, nsMacMessagePump.cpp... without that call, 
the Mac OS defaults to the desktop size - 3 pixels all round.) At the moment, the 
current settings seem fairly arbitrary: top + 3, left + 3, right - 64, bottom - 3 
(unless there's a good reason already?)

* User state: whatever the user last resized to.

* Opening a new window: still thinking about this one, I'd perhaps suggest the 
current window state (user or not) plus an offset, or the last user state (if no 
relevant windows are open).

* Option-zoom: probably not needed (ref: bug 42578).

Right. What think you?

Comment 1

[Peter Trudelle]

Thanks for your comments.  I don't really have time to discuss them right now,
but feel free to file bug reports on specific behaviors you think should be
changed.  I will say that I've never liked windows to go full-screen when
zooming on a large monitor, much better if they could be smarter about the
content.  I also hate the 4.x behavior of setting the window sticky pref based
on the last window *closed*.
->future, add meta tag.

Comment 2

[Henri Sivonen (:hsivonen)]

"Me, too" to what Trudelle wrote. Zoom box should set the window width to the smallest 
width that makes the horizontal scrollbar go away (but not smaller than some constant 
eg. 450px or may be a clever number of ems). Zooming to the minimum window size 
required to display content is consistent with Finder's zoom box behavior.

A new window should, in my opinion, be offset about 16px down and about 8px right from 
the current window. The size of the new window should be the same as that of the current 
window (or a bit smaller if the window would go partially off the screen in the same size).

Comment 3

[Terence Tan]

OK, I'd better make a few more comments.



Smart window sizing (window automatically sizes to fit the content) is a very 

nice feature, 4xp, and I'd love to see it. However, from here it seems that it's 

not going to make it into the product any time soon... it's not a trivial thing 

to code. So all my suggestions were based on the fact that we don't get smart 

window sizes. (I remember seeing a bug on it before, but can't find it now.)



Window tiling (cascading) on new windows: ref. bug 25455 for the issues involved 

with that.



Having new windows inherit the size of existing ones: ref. bug 17149 for those 

issues.

Comment 4

[bugzilla]

For what it's worth, when I hit the zoom box and it opens up to full screen 
except for the strip on the right side-- I found that very annoying and was 
suspecting it was a bug or something.  So every time I have to manually drag the 
window to the right to fill up the screen.  I didn't realize it was intentional.  
What's the advantage of leaving that area exposed?

Comment 5

[Peter Trudelle]

Traditionally, it has been done to provide access to mounted volumes and Trash.

Comment 6

[Terence Tan]

I'd strongly advocate giving users as much screen real estate as possible
(especially on small screens; I suppose it could be bothersome for large
screens). Web designers in particular will often assume that the user has given
them as much screen width as they can; it's premium space... scrolling
left-right isn't as much fun as scrolling up-down.

Comment 7

[Peter Trudelle]

That's generally true up to about 800X600, but as you approach 1600X1200 it 
becomes an absurd waste of screen space to have most windows taking up more 
than about half the width of the screen (when using default fonts).  BTW, I've 
always thought vertical space was premium, because there's almost always less 
of it.

Comment 8

[Matthew T (active 1999-2002)]

Most Web pages are both far too wide and far too long for their own good
(inasmuch as pages which are nice to the user will tend to be more popular).
Widths of pages will decrease over time as things like the sidebar, and IE's
Explorer Bar, teach Web authors that they can't assume they have the whole width
of a screen any more (and as using CSS floaters becomes more viable, so complex
layouts can more gracefully degrade into narrow viewports). And lengths of pages
will decrease over time as connection speeds increase, and as Web authors
realize that clicking really is faster than scrolling.

But for another five to ten years, most Web pages are going to be such that a
Finder-like zoom (sizing the window to the minimum size required to fit the
content) will have no practical effect whatsoever. So I think it is probably
better to use the zoom box to `maximize' the window, rather than to try to
expand or contract to fit the available content.

So, I suggest:
* Default user state: 3px around each side, except 64px on the right for access
  to volumes and Trash. (One day we will be able to drag bookmarks etc to the
  Trash ...)
* Standard state: 3px around each side, no exceptions.
* Option+zoom: not implemented.
* New window displacement: enough to see a decent chunk of the throbber in every
  non-frontmost window, so that you can tell if the non-frontmost page has
  finished loading.

Comment 9

[timeless]

mpt: are you basically saying that you like our current behaviors?

Remember, the bookmarks window does not have to get the same sizing as the 
browser window.

Although it'd be neat if i could trash a graphic or java applet or plugin 
object and have it go to its non loaded form (and be cleaned out of cache), but 
that's another bug.

Comment 10

[Terence Tan]

Smart sizing would be very welcome. But I understand that it's difficult to
code. It all becomes a case of effort involved vs payoff. I think we're stuck
with dumb (hard-coded) sizing for now.

In this case, I don't think the bookmarks window must have the same sizing
behaviour as the browser window (and mail-news, and whatever). That's because
the window sizing is hard-coded into a single point in the window code
(nsMacMessagePump.cpp, from memory). Everything behaves the same. So one of the
hard things we have to do is find a solution which fits everything.

There are several issues at hand here, but then it's a very general bug.

Comment 11

[Peter Trudelle]

->danm

Comment 12

[Andrew Thompson]

Ho hum, more fuel for the opinions fire I suppose, but here goes....

There is defined bahaviour for how this should be, and its basically "what the 
Finder does". Now I recall reading something, that Apple used to have some 
sample code to do this, but AFAICT this has been superceded by a standard 
toolbox function, and the code given here:

http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/WindowManager/P
rogWMacOS8.5WindowMgr/WindowMgr.1c.html

(or search for ZoomWindowIdeal at developer.apple.com) - if we're not using 
this sample code already I suspect we should be. If anyone wants a seperate bug 
for this ask and I'll make one. 


Still need to calculate sizes though so other comments I would make:

Hardcoding heights should be done very carefully, you might want to be calling 
GetMenubarHeight, though its sounds like the window automatically avoids the 
menubar if placed at 0,0

Please please keep the strip down the right hand side - I rely on this 
behaviour so I can get my disks and I'd filling the whole screen extremely 
annoying whatever the resolution.

Option Zoom means ignore user and standard size and "maximise" in the Finder 
and many other apps which mimic it, so I'd say

The ideal is something like this:

* Default user state: smart sizing
* Standard state: smart sizing
* Option zoom: fill screen apart from pixels on right for trash etc

This is what the Finder does, and it would also support those people who want 
to have maximised windows that do cover the trash so long as new windows copy 
the size, as they'd only need to resize the first window they open manually. 
(or shift-option could be a super-maximise)

However, since we can't have smart sizing soon I'd think 

* Default user state: fill screen apart from pixels on right for trash etc 
* Standard state: fill screen apart from pixels on right for trash etc
* Option zoom: fill screen apart from pixels on right for trash etc

Which means option zoom is redundant, but it does what its supposed to do and 
thus can be left alone when smart sizing is implemented for the other 2 options.

One last thing - using the size of the last window closed can be really 
upsetting because it means new browser windows end up being the size of the  
advertising popup (i.e. really small) that's just been closed.

I agree - this bug is getting messy. Proposal for how to split it?

Comment 13

[Terence Tan]

I've filed bug 80431 on, in essence, whether the zoom box should resize the
window to full-screen or full-screen-with-64-pixel-gap-on-the-right.

Comment 14

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 15

[Dan M]

I'm a bad owner for this bug since I no longer have access to a Mac. So I'm
dumping it on sfraser. Simon, this bug is scheduled to be resolved. It could
stand to be saved if it's still a problem, which it could be even on OS X.

Comment 16

[bbz]

The zoom button still zooms to full-screen-with-64-pixel-gap-on-the-right, which is highly annoying as Firefox is the only Mac application I've seen with this behavior.  I didn't even realize that it was intentionally done so the user can see the desktop icons until I tracked down this bug and bug 80431.

Please please please, can we remove the 64-pixel gap?  It's very annoying to have to resize every window I want to maximize with a 64 pixel horizontal drag.  Mac OS X has expose to allow me to quickly get to the desktop by hitting a function key or going to a screen corner.  Also, it looks like part of the motivation is to let users drag bookmarks to the trash.  In OS X, the trash is in the dock so access to the desktop doesn't even support that feature.

Comment 17

[bbz]

I've fixed the 128 pixel gap issue.  NO other Mac application that I know of implements maximize as maximize-but-leave-gap-for-icons and I bet there are thousands of Mac firefox users who are sick of manually maximizing their firefoxes too.  The patch only removes the offending code so is pretty safe.

In the spirit of the original bug poster, below is the current state of the browser with my patch added.  It looks like other bugs brought other UI annoyances into line (like the cascading window from the full screen state.)


Maximized size-state: window covers entire screen (except menu bar & dock)
User size-state: whatever the user last resized to.

The Maximize button: toggles between the two states.
Resizing a window: sets the user state-size.  Yes, you can set the user state to the whole screen, effectively "disabling" the maximize button.

Opening new window: window opens in size-state of current window (maximized or user), or last of closed window if none open.   If maximized, new window is same size/location, if user, window cascades toward the lower left without going off the screen.

Option-zoom: same as zoom.  if someone else wants to implement it as the 
size-to-fit-to-page "smart window sizing", feel free.  Please do not make it the non-option zoom.  The maximize button should always make the window cover as much of the screen as possible.

Comment 18

[bbz]

Attachment: fix to remove the 128-pixel gap on the right size of a "maximized" window.

I believe this is the last bit to fix all of this bug.

Comment 19

[Terence Tan]

This bug is targeted at the Suite, not Firefox (ye gods, did I really file this bug 5 years ago? Firefox wasn't around then). I guess we could file a corresponding bug on Firefox. And Thunderbird; that's got a similar behaviour.

Although the patch as-is looks like it'll fix all 3 - if that's wanted.

Comment 20

[John Flynn]

I found an interesting bug in Firefox 3b5 that perhaps belongs under this bug.

If you maximize Firefox, then quit it, restart it so that it starts maximized and zoom it, it will forget the previous zoomed size. Instead it will open as a tiny little square window on the left side of the screen that needs to be manually sized to the desired dimensions.

This happens on both my Macbook Pro (single head) and my Mac Pro (dual head), so it seems to be a general bug.

I can open a new bug for this, but this bug seems to cover it so I thought I'd put it here. Let me know if you want me to open a new bug and I shall.

Comment 21

[Ian Tommins ('thelem')]

I don't think its quite a duplicate, but see also bug 232919

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:enndeakin, maybe it's time to close this bug?

Comment 23

[Stephen A Pohl [:spohl]]

We have been tracking window sizing issues in various other bugs and keeping this bug open will not provide any meaningful help.