Maximized windows collapse to their unmaximized size when moving them by dragging toolbar or statusbar

VERIFIED FIXED in mozilla1.9.3a1

Status

()

Core
XP Toolkit/Widgets: XUL
P2
normal
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: mstange, Assigned: mstange)

Tracking

(Depends on: 1 bug, {regression, verified1.9.2})

Trunk
mozilla1.9.3a1
All
Mac OS X
regression, verified1.9.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta2-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

8 years ago
STR:
 1. Make your window small.
 2. Click the window's zoom button.
 3. Drag the status bar.

Expected results:
This shouldn't change the window size.

Actual results:
The window collapses to its previous size.

This is most certainly a regression from the patch in bug 429954 that started treating zoomed windows as maximized. Un-maximizing maximized windows before moving them certainly makes sense on Windows, but it doesn't make sense on Mac.
If bug 517396 is a blocker, this should also be a blocker.
Flags: blocking1.9.2?
(Assignee)

Comment 2

8 years ago
Created attachment 408922 [details] [diff] [review]
v1: reset the size mode in the platform implementations instead

Neil, do you think this is the right approach?
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #408922 - Flags: review?(neil)

Comment 3

8 years ago
Comment on attachment 408922 [details] [diff] [review]
v1: reset the size mode in the platform implementations instead

Seems reasonable to me.
Attachment #408922 - Flags: review?(neil) → review+
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
(Assignee)

Comment 4

8 years ago
Created attachment 409303 [details] [diff] [review]
v2

Now with test and indentation style that matches the context. Roc, could you review the widget/ changes?
Attachment #408922 - Attachment is obsolete: true
Attachment #409303 - Flags: review?(roc)
Attachment #409303 - Flags: review?(roc) → review+
This would be pretty easy to write a test for, wouldn't it?
(Assignee)

Comment 6

8 years ago
There's a test in that patch. :-)
(Assignee)

Comment 7

8 years ago
http://hg.mozilla.org/mozilla-central/rev/f8eea9f6143a
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
(Assignee)

Updated

8 years ago
Flags: in-testsuite+
(Assignee)

Updated

8 years ago
Depends on: 526236
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091104 Minefield/3.7a1pre ID:20091104031046
Status: RESOLVED → VERIFIED
(Assignee)

Comment 9

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/79bfa41e64b5
status1.9.2: --- → final-fixed
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
Comment on attachment 409303 [details] [diff] [review]
v2

>+  var win = wm.getMostRecentWindow("navigator:browser");
>+  var oldX = win.screenX, oldY = win.screenY;
...
>+  win.restore();
>+  is(win.outerWidth, oldWidth, "restored window has wrong width");
>+  is(win.outerHeight, oldHeight, "restored window has wrong height");
Unfortunately you didn't check that the window was restored before grabbing the old width/height, so if you run the test in a maximised window it fails...
You need to log in before you can comment on or make changes to this bug.