429952 - after resizing a window, new windows do not open with the same size and position as it.

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Jeff Mann]

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

After moving, resizing, or maximizing the frontmost window, new windows opened via File->Open or command-N do not open with the same size/position/maximize state as frontmost window, unless the frontmost window has lost and regained focus at least once. This applies, for example, to the first window upon opening Firefox.

Reproducible: Always

Steps to Reproduce:
1. Open a new window. Or, just start Firefox (without session restore).
2. Manually resize, move, or maximize the window. Do not click on any other windows.
3. Open another new window.
Actual Results:  
Second new window opens with size/position of first window *before* it was resized/moved/maximized. 

(Note: if you now close the second new window or just click on the first window, and then open another new window, it will open as expected). 

Expected Results:  
Second new window should open with size/position of first window *after* it was resized/moved/maximized.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042109 Minefield/3.0pre

This is not reproducible for me on Windows. I see two windows with the same size.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Please renominate if you get reproducible steps and a confirmation.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Oops, sorry, I missed the OSX-onlyness. I can reproduce this. Don't think it blocks, though.

Tomcat: can you help us with a regression range?

Comment 4

[Jeff Mann]

Some additional information after further testing: 

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 the behaviour in the original description.

However, if the last window closed in Firefox 2 was maximized, all new windows in Firefox 3 always open maximized, and always (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 429954

Comment 5

[DP]

Additional reproducible clues: 

0) OS X 10.4.11 Firefox 2.0.0.14
1) Open a FF window and maximize it--green button (note: desktop icons are visible on the right edge of the window)
2) Open a new window
3) Window position is superimposed (Good Thing™)
4) Drag the bottom right corner to fill the window (note: desktop icons are no longer visible)
5) Open a new window
6) Window position is now tiled (top left position is ~(+30, +30) from superimposed position (not a Good Thing™) :-\

(/|\) Peace

Comment 6

[Jeff Mann]

DP, thanks for that report but this is a new bug in firefox 3, it's not present in firefox 2. your comment #5 belongs somewhere else, although since that behaviour is no longer present in firefox 3, there's probably not much point.

Comment 7

[Markus Stange [:mstange]]

Jeff, do you still see this with a recent trunk nightly?

Comment 8

[Jeff Mann]

It's improved in the latest nightly, but not completely fixed. There are still cases when a new window will open with the size or position of (or related to) the previous window before it was resized - unless the previous window has lost and regained focus. Unfortunately it's not always reproducible anymore.

For example, open a new window, then move but do not resize it. Then open another new window. The second window will usually, but not always, open at the position of the first window before it was moved. If not, keep opening and moving windows a few times and you'll see it. Likewise, opening a new window after resizing but not moving the first window, will sometimes but not always cause the second window to open with the size of the first window before it was resized. Or, it may instead open with the correct size, but an incorrect horizontal offset. There also seems to be some issues with windows that are the full height of the screen, but not maximized.

I can't pin it down to being completely consistent yet. I don't think I'm going to have the time to spend to track it down, unfortunately.

Comment 9

[Markus Stange [:mstange]]

Hmm. I was only able to reproduce it with zooming, which didn't persist the position, which I fixed in bug 509660.

Comment 10

[Jeff Mann]

It's easy for me to reproduce some of the misbehaviour, for example:

1. open a new window and resize it to a small-ish size, and move it to the centre of your screen.
2. press command-n to make a new window. it will open (correctly) with the same size as the first window, and with a position offset slightly to the right and down from the first.
3. drag the new window to a new position. do not click on the previous window, and do not resize the new window.
4. press command-n to make another new window. it may open correctly offset from the previous window, or, it may open in exactly the same position the previous window was in before you moved it.
5. repeat step 3 and 4. eventually you will see it open in the wrong position. 

note in step 4, it opens in exactly the same position as the previous window before you moved it, with no offset. it seems like maybe it's opening relative to the window before that, rather than to the window-before-you-moved-it.

you can get the same behaviour with resizing:
1. open a new window and resize it to a small-ish size, and move it to the centre of your screen.
2. press command-n to make a new window. it will open (correctly) with the same size as the first window, and with a position offset slightly to the right and down from the first.
3. resize the new window. do not click on the previous window, and do not drag/move the new window.
4. press command-n to make another new window. its position will be correctly offset from the previous one. it may open correctly sized the same as the previous window, or, it may open with the same size the previous window was before you resized it.
5. repeat step 3 and 4. eventually you will see it open with the wrong size. 

I also had at least once, a case where a new window opened not-maximized when the previous window was maximized and dragged. However, it seems difficult to reproduce that.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090817 Minefield/3.7a1pre

Comment 11

[Markus Stange [:mstange]]

OK, I can reproduce it with moving the window, but only if I drag the titlebar of the window (and not e.g. the statusbar). I can't reproduce it with resizing.

Comment 12

[Jeff Mann]

Attachment: screenshot of incorrect size for new windows

shows a typical occurence of resizing bug: i created the rearmost of the four visible windows, then did command-n, and the second window appeared, properly sized. i then resized the second window to be taller and thinner. then did command-n again, and the third window appeared, also properly sized. i then resized that window to be shorter and wider. then i did command-n, and the fourth (frontmost) window appeared, improperly sized as tall and wide, i.e. the same as the third window before it was resized.

Comment 13

[Markus Stange [:mstange]]

Can you reproduce this in a fresh profile, too?

Comment 14

[Jeff Mann]

yes.

Comment 16

[Josh Aas]

I found two ways to reproduce this bug on macOS 26.5 with Firefox 150. Both methods reproduce this 100% of the time.

1. 500ms Timer Race

• Open a first window on the screen, taking up most of the screen.
• Open a second window using cmd-n, it will be the same size at the first (slightly offset as expected)
• Put your fingers on the cmd-n buttons so you can do it really fast, but don't actually do it yet
• Resize the second window to be roughly half the width of the first
• Within less than half a second (500ms) of completing the resize, hit cmd-n
• The new window will incorrectly be the size of the first window, not the second one

This is because there is a 500ms timer that runs before size changes are persisted, so the new size of the second window is not persisted yet when you created the third window.

I'm not really sure this case is worth fixing.

2. Minimizing Bug

• Open a first window on the screen, taking up most of the screen.
• Open a second window using cmd-n, it will be the same size at the first (slightly offset as expected)
• Resize the second window to be roughly half the width of the first
• Minimize the second window using cmd-m
• Wait a few seconds, then deminimize the second window by clicking on its dock icon
• Hit cmd-n to open a third window
• The new window will incorrectly be the size of the first window, not the second one

This happens because when you minimize the second window, the first window becomes the main window and its size is persisted. When you deminimize the second window and it becomes the main window again, its size should be persisted but it isn't. For some reason the new main window persists its size when you minimize a windows, but when you deminimize a window its size is not persisted. This behavioral asymmetry causes the bug.

I think this should be fixed.

Comment 17

[Josh Aas]

Attachment: Bug 429952 - macOS: Fix incorrect sizing of new window after deminmizing another window. r?#mac-reviewers

Comment 18

[Josh Aas]

The attached patch fixes method #2, but I'm not 100% sure it's the right way to fix it yet so holding off on review.

Comment 19

[Josh Aas]

I found a better way to fix repro method #2. Requested review.

Again, I don't think we should fix repro method #1. That is an architectural choice for a reason and it would be hard to know what would break if we undo it.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e15beb118eb0
https://hg.mozilla.org/integration/autoland/rev/3d8a0d7f8ace
macOS: Fix incorrect sizing of new window after deminmizing another window. r=mac-reviewers,bradwerth

Comment 21

[amarc]

https://hg.mozilla.org/mozilla-central/rev/3d8a0d7f8ace