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.

Categories

(Core :: Widget: Cocoa, defect, P2)

All
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta2-fixed

People

(Reporter: bugzilla2, Assigned: mstange)

References

Details

(Keywords: verified1.9.2, Whiteboard: [polish-hard] [polish-interactive][polish-p2])

Attachments

(3 files)

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.
Flags: blocking-firefox3?
Version: unspecified → Trunk
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
Flags: blocking-firefox3?
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
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
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.
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
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.
Duplicate of this bug: 433245
Duplicate of this bug: 437051
Duplicate of this bug: 437873
Duplicate of this bug: 440148
Duplicate of this bug: 444715
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).
Duplicate of this bug: 477534
Flags: wanted1.9.0.x+ → wanted1.9.1+
Duplicate of this bug: 480431
Assignee: joshmoz → nobody
Flags: wanted1.9.2+
Priority: P1 → P2
Hardware: PowerPC → All
Duplicate of this bug: 439997
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]
Duplicate of this bug: 509352
I've been hitting this bug really a lot, are other people seeing this on a pretty regular basis?
Flags: blocking1.9.2?
Attached patch v1Splinter Review
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)
Attachment #393870 - Flags: review?(joshmoz) → review+
http://hg.mozilla.org/mozilla-central/rev/b52fa2372a3a
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)
Attachment #394176 - Flags: review?(joshmoz) → review+
http://hg.mozilla.org/mozilla-central/rev/71f1dacf8bdd
Status: REOPENED → RESOLVED
Closed: 11 years ago11 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
Depends on: 517396
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.
Attached patch testSplinter Review
Flags: in-testsuite?
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
Keywords: verified1.9.2
Duplicate of this bug: 535215
Blocks: 573598
Depends on: 715867
You need to log in before you can comment on or make changes to this bug.