Closed
Bug 429954
Opened 16 years ago
Closed 15 years ago
windows that open already maximized will un-maximize to a teeny-tiny window in upper left.
Categories
(Core :: Widget: Cocoa, defect, P2)
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)
4.34 KB,
patch
|
jaas
:
review+
|
Details | Diff | Splinter Review |
1.13 KB,
patch
|
jaas
:
review+
|
Details | Diff | Splinter Review |
3.36 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•16 years ago
|
||
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
Comment 2•16 years ago
|
||
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?
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.
Comment 10•16 years ago
|
||
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
Flags: wanted1.9.2+
Priority: P1 → P2
Hardware: PowerPC → All
Comment 14•15 years ago
|
||
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]
Comment 16•15 years ago
|
||
I've been hitting this bug really a lot, are other people seeing this on a pretty regular basis?
Flags: blocking1.9.2?
Assignee | ||
Comment 17•15 years ago
|
||
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.
Attachment #393870 -
Flags: review?(joshmoz) → review+
Assignee | ||
Comment 18•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/b52fa2372a3a
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2b1
Assignee | ||
Comment 19•15 years ago
|
||
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 → ---
Assignee | ||
Comment 20•15 years ago
|
||
[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+
Assignee | ||
Comment 21•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/71f1dacf8bdd
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.2b1 → mozilla1.9.3
Comment 22•15 years ago
|
||
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
Updated•15 years ago
|
Target Milestone: mozilla1.9.3 → mozilla1.9.3a1
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Assignee | ||
Comment 23•15 years ago
|
||
I need to fix bug 517396 before this can land on 1.9.2. Also, tests.
Comment 24•15 years ago
|
||
If this is a blocker, bug 517396 should also be a blocker.
Assignee | ||
Comment 25•15 years ago
|
||
Updated•15 years ago
|
Flags: in-testsuite?
Assignee | ||
Comment 26•15 years ago
|
||
pushed the test: http://hg.mozilla.org/mozilla-central/rev/1cc99d296ad5
Flags: in-testsuite? → in-testsuite+
Assignee | ||
Comment 27•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2d9099ec4d6f http://hg.mozilla.org/releases/mozilla-1.9.2/rev/104a62479123
status1.9.2:
--- → final-fixed
Comment 28•15 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•