Window maximizing seriously horked

RESOLVED FIXED in mozilla1.0

Status

--
major
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: mikepinkerton, Assigned: danm.moz)

Tracking

({regression})

Trunk
mozilla1.0
PowerPC
Mac OS X
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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
(Reporter)

Comment 1

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

bad regression.
Keywords: mozilla0.9.9, nsbeta1, regression

Comment 2

17 years ago
*** Bug 125758 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

17 years ago
Created attachment 70585 [details] [diff] [review]
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.
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 4

17 years ago
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.
Status: NEW → ASSIGNED
(Reporter)

Comment 5

17 years ago
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.
Attachment #70585 - Flags: review+

Updated

17 years ago
Attachment #70585 - Flags: needs-work+

Comment 6

17 years ago
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.

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 7

17 years ago
Created attachment 73068 [details] [diff] [review]
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.
Attachment #70585 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0
(Reporter)

Comment 8

17 years ago
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*
Attachment #73068 - Flags: review+
(Assignee)

Updated

17 years ago
Blocks: 112230

Comment 9

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

sr=scc
Attachment #73068 - Flags: superreview+

Comment 10

17 years ago
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
Attachment #73068 - Flags: approval+

Comment 11

17 years ago
Please, let's test this patch before it goes in. Sorry I haven't had time.
(Assignee)

Comment 12

17 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.