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
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
*** Bug 125758 has been marked as a duplicate of this bug. ***
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.
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
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+
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.
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
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+
Comment on attachment 73068 [details] [diff] [review] even less shimmy than before sr=scc
Attachment #73068 - Flags: superreview+
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+
Please, let's test this patch before it goes in. Sorry I haven't had time.
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
You need to log in before you can comment on or make changes to this bug.