Closed Bug 429954 Opened 12 years ago Closed 11 years ago
windows that open already maximized will un-maximize to a teeny-tiny window in upper left
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042004 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042004 Minefield/3.0pre New in Firefox 3: If a new window opens already-maximized (including the first window upon opening Firefox), then pressing the green button will un-maximize it to a teeny-tiny window showing not much more than the "back" button. Reproducible: Always Steps to Reproduce: 1. Close all windows, then open a new window. 2. If the window does not open already-maximized, then maximize it with the green button, close it, and open another new window, which should now open already-maximized. 3. Press the green button to un-maximize it. Actual Results: Window un-maximizes to a tiny window in upper left of screen. Expected Results: Window should un-maximize to size/position of previous window.
Confirmed. I've been seeing this for a while ... but I was lazy and didn't report it.
Assignee: nobody → joshmoz
Component: OS Integration → Widget: Cocoa
Product: Firefox → Core
QA Contact: os.integration → cocoa
I don't know whether this should block, or whether a fix can wait for a point release. Asking for blocking to get it on the radar.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is frustrating when it happens but I don't think it happens often enough that we'd block the release on this. We should definitely make this a priority for a 1.9.0.x. release though.
Priority: -- → P1
Some additional information after further testing, the bug can also manifest as "windows always open maximized". The behaviour of this bug depends on what happened the last time you ran Firefox 2. If the last window closed in Firefox 2 was un-maximized, you get this (using OS X): 1. Run firefox 2, make the window un-maximized and move it away from the upper left corner, eg. to the middle of your screen. 2. Quit Firefox 2 and open Firefox 3. The first window in Firefox 3 will open at the same size/position as the last one in Firefox 2. 3. Maxmize this window, then close it, then open another new window. Expected result: new window should open maximized Actual result: new window opens with a "maximized" size, but at the same position as previous unmaximized window. 4. Press the green button to maximize this window (i.e., move it to the top left), then close the window, and open a new one. It will open already-maximized. 5. Continue from step 3 in original description; from now on it will behave as in original description. If the last window closed in Firefox 2 was maximized, you get instead a "windows always open maximized" behaviour: 1. Run firefox 2, make the window maximized. 2. Quit Firefox 2 and open Firefox 3. The first window in Firefox 3 will open maximized. 3. Press the green button to un-maximize it, it will return to the size/position of the previously un-maximized window in Firefox 2, as expected. 4. Close the window and open another new window. Expected result: window opens at size/position of previous un-maximized window. Actual result: window opens maximized. All subsequent new windows open maximized, and will (initially) un-maximize to size/position of last closed window in Firefox 2, regardless of any resizing of windows in Firefox 3. This bug likely interacts with bug 429952.
This bug is also somewhat related to bug 232919, since the green button shouldn't be maximizing windows in the first place (per Apple's HIG).
Assignee: joshmoz → nobody
Priority: P1 → P2
Hardware: PowerPC → All
This bug's priority relative to the set of other polish bugs is: P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable. Only occasionally encountered (as opposed to constantly), but super obvious and clearly broken and wrong when it is encountered.
Whiteboard: [polish-hard] [polish-interactive][polish-p2]
I've been hitting this bug really a lot, are other people seeing this on a pretty regular basis?
Apple's explanation of the way the zoom button works is here: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/zoom: It says "If there is no saved user state because there has been no previous zoom, the size and location of the window do not change." - but that statement is apparently wrong. What really happens is that the window resizes to the size that it was created with. However, nsAppShellService::JustCreateTopWindow specifies 1x1 as the creation size, so we'll end up with a very small window. The patch now consists of two parts. The first part is the addition of mHasEverBeenZoomed and windowShouldZoom, where we just disallow zooming in those cases where we'd zoom to the creation size. The rest of the patch makes the zoomed state be reflected in the window's sizeMode (as nsSizeMode_Maximized). That way, zooming a window doesn't change the size that Gecko stores for opening new windows. Let's look at an example: 1. Open a window and make it small, somewhere in the center of the screen. (Now we're in nsSizeMode_Normal, both with and without the patch.) 2. Zoom the window. (without the patch: normal resize - with the patch: sizemode changes to maximized) 3. Open a new window. without patch: window is resized to the zoomed size without actually being zoomed - with patch: window is resized to the last stored "normal" size and subsequently zoomed (by SetSizeMode(nsSizeMode_Maximized)). So when you now press the zoom button (with the patch), Cocoa uses the size that was set before SetSizeMode was called, i.e. the original size of the original window.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #393870 - Flags: review?(joshmoz)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2b1
Backed out because a test caught errors in the size mode handling. http://hg.mozilla.org/mozilla-central/rev/b3631e1453f2 http://hg.mozilla.org/mozilla-central/rev/c8e0d1fa54c5
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
[window isZoomed] also returns YES for windows that can't be resized, even though they're not zoomed. The test that caught this minimized and restored a non-resizable window and wondered why it had suddenly become maximized.
Attachment #394176 - Flags: review?(joshmoz)
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.2b1 → mozilla1.9.3
Looks great. Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090814 Minefield/3.7a1pre ID:20090814032252
Status: RESOLVED → VERIFIED
Target Milestone: mozilla1.9.3 → mozilla1.9.3a1
Flags: blocking1.9.2? → blocking1.9.2+
I need to fix bug 517396 before this can land on 1.9.2. Also, tests.
If this is a blocker, bug 517396 should also be a blocker.
pushed the test: http://hg.mozilla.org/mozilla-central/rev/1cc99d296ad5
Flags: in-testsuite? → in-testsuite+
Verified fixed on 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre ID:20091106033745
You need to log in before you can comment on or make changes to this bug.