125711 - Window maximizing seriously horked

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Mike Pinkerton (not reading bugmail)]

open a new window on osx (build from 2/14/02 debug)
click maximize button
click it again

expected:
window maximizes, then goes back to normal

actual:
window shimmies, and repositions itself, expands in one direction, then the
other, leaving the bottom off the bottom of the screen. this process takes
several seconds. clicking maximize again doesn't restore the original sizing,
but one of the intermediate stages. getting the window back to normal takes a
lot of resizing and moving about.

the shimmying is worse on my 2nd monitor, but happens on both

Comment 1

[Mike Pinkerton (not reading bugmail)]

this also happens when a page maximizes itself (like some pr0n pages, not that
i'd know anything about that).

bad regression.

Comment 2

[Simon Fraser [no longer active]]

*** Bug 125758 has been marked as a duplicate of this bug. ***

Comment 3

[Dan M]

Attachment: take the shimmy out of carbonized zooming

Yow. Looks like the Carbon libraries sneak an explicit resize into
::ZoomWindow. We weren't expecting that and all sorts of dumb things happen.
This patch fixes zooming on my Carbon build. Diligence would suggest that I
check its effect on old-school builds, too. Ick. Soon as I can locate three
hours I don't need my machine for.

Comment 4

[Dan M]

Tested the above patch on a non-Carbon build (what's that, Silica?). Beauty
everywhere. Hmmph. I wonder why zooming worked at all. Looking for reviewer luv.

Comment 5

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 70585 [details] [diff] [review]
take the shimmy out of carbonized zooming

r=pink

can you cleanup the spacing in nsMacWindow.h since you're touching those lines
anyway? The spacing of the member names is inconsistent.

Comment 6

[Simon Fraser [no longer active]]

Comment on attachment 70585 [details] [diff] [review]
take the shimmy out of carbonized zooming

This patch is not good. If I maximize the window (CFM OS X build), then go to
resize it smaller, it first jumps to the user size before starting the resize.
It's nasty, and probably called by that ZoomWindow() call there.

I don't think ZoomWindow should be called in the resizing code. It should only
be called when really doing a mazimize. If the user resizes the window when
it's mazimized, then they are changing the maximized zoom state, not the user
state. This means that a subsequent zoom in, followed by a zoom out, would
return the window to that user-specified maximized state. This is how other Mac
applications work.

Comment 7

[Dan M]

Attachment: even less shimmy than before

Simon: I see the OSX glitch you mentioned: a zoomed window will jump at the
beginning of a mouse resizing operation. This doesn't happen on OS9; it must be
because of that extra resize coming from within the ZoomWindow function.
  However I don't follow your assertion about zoomed windows behaviour. I read
your statement above as saying that zooming a normal ("user") state window to
maximized ("standard") state, resizing it, then zooming again should return to
the original normal size, then zooming again should return to the changed
maximized size. It sounds believable and all, but this isn't happening in my
testing. All apps that I've tried including TextEdit, Roxio Toast, IE and Nav 4
all seem to have a fixed maximized size. Resizing while maximized and then
zooming again returns you to the original maximized size. (Though IE, if you
size the window larger while maximized, seems to find a supermaximized size. I
haven't quite figured out what it's trying to do there. But basically it also
behaves the same way.)
  In fact I'd say that the behaviour you're describing would reinstate the
confusion reported in bug 107937, where people were complaining that they
couldn't tell which zoom state a window was in, and so Mozilla surprised them.
  So here's my current favourite patch for this bug. Zoom a normal window to
its maximized size, resize it, zoom again and it returns to its maximized size.
And there's no shimmy on OS9 or OSX, thereby fixing this bug and keeping 107937
fixed.
  If this is bad, I'm going to need examples and diagrams.

Comment 8

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 73068 [details] [diff] [review]
even less shimmy than before

+  // we've just finished sizing, so make our current size our user state,
+  // and switch to the user state
+  StPortSetter setOurPort(mWindowPtr);
+  Rect bounds;

I would add a StOriginSetter, just to be safe:

+  // we've just finished sizing, so make our current size our user state,
+  // and switch to the user state
+  StPortSetter setOurPort(mWindowPtr);
+  StOriginSetter resetOrigin(mWindowPtr);
+  Rect bounds;

+// we're resizing. if we happen to be zoomed ("standard" state)

Is there more here? This feels like a sentence fragment.

both those are nits though, r=pink.

I think apple originally intended zoom state to behave like simon mentioned (i
think it's documented that way in IM vol IV), but with the advent of the
MSWindows "maximized" concept, apps drifted that way on their own accord. i
think everyone now accepts zoomed to mean "maximized like on windows". *shrug*

Comment 9

[Scott Collins]

Comment on attachment 73068 [details] [diff] [review]
even less shimmy than before

sr=scc

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 73068 [details] [diff] [review]
even less shimmy than before

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 11

[Simon Fraser [no longer active]]

Please, let's test this patch before it goes in. Sorry I haven't had time.

Comment 12

[Dan M]

Ah man, it's been a week. Simon, I didn't notice your request before checking in. 
Sorry. But in my favour, the pre-patch behaviour is really horked. Post-patch 
behaviour is a clear improvement. Extreme caution seems unnecessary. It'll be 
easier to test now and we can always tweak it again if it comes to that.