Window positions not saved or restored correctly

RESOLVED FIXED in mozilla0.9.5



16 years ago
9 years ago


(Reporter: Warner Young, Assigned: Dan M)


Windows 98

Firefox Tracking Flags

(Not tracked)



(2 attachments)



16 years ago
This broke some time in May, and then was fixed briefly, and broke again. 
Basically, if I open a new browser window and then close that window, the next
time I start Mozilla, the browser will appear in the new position.

Expected: browser should appear in the same position as the last *closed*
browser window.

Results: browser appears in the position of the last *opened* browser window.

Comment 1

16 years ago
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Assignee: pchen → danm
QA Contact: sairuh → claudius

Comment 3

16 years ago
What we have here is a clash of expectations. I think you're asking that we 
reinstate the odd behaviour of Navigator 4.x. We made a conscious decision to fix 
that in Mozilla, saving/restoring a window's state when it's opened or moved, 
rather than when it's closed. I find the new scheme way more natural and 
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 4

16 years ago
Danm, please reconsider changing this back, or at least provide an option for
this. The problem is this: I want my (non-maximized) browser window to open in
the same place each time I start Mozilla. But if I open a bunch of new browser
windows after that, it means that the next time I start Mozilla, it will open in
*some random location*, based on how many windows I opened in the previous
session. Given this scheme, you might as well not save the browser position, and
just make it random.

Also, Netscape 4.x's method wasn't odd. Most other Windows apps behave the same
way, as far as I can tell. Certainly IE 4.x does (just checked it).  In any
case, some testing shows the window position seems to be saved only on open, not
move:  start Mozilla.  Open new browser window.  Close new browser window.  Move
1st window somewhere else, and then move it back.  Close 1st window.  Start
mozilla again;  it appears in the same position as the "new" window, not the
last position to which it was moved.

Comment 5

16 years ago
It doesn't behave that way on Win2K. Given the above steps, relaunched Mozilla's 
first window opens in the last position the first window was moved to, just 
before it was closed. Which is pretty much the way you'd want it. Sounds like 
maybe something's wrong with the timer-driven persistence of window state, but 
only on Win98 builds. Ugh. Know anyone who has a Win98 development system?
Keywords: helpwanted
Resolution: INVALID → ---

Comment 6

16 years ago
Danm, I've been trying all the apps I can find, and they fall into 3 general
classes: those that allow multiple instances and save window positions, those
that  allow multi instances but don't save position, and those that only allow 1

All the apps I can find in the first class behave as I expect: they save the
position of the last closed window.  Windows Explorer, Internet Explorer,
Windows Write, CorelDraw 9, Netscape 4.x all behave this way.

Another problem I can think of is links that open a new window automatically. 
Under the current scheme, any time I hit such a link, the saved window position
for Mozilla will change.

Given this, could you please consider either reverting the window position code
to the previous method, or at least provide an option to choose which method?

Comment 7

16 years ago
  I think I'm on the same page as you now. Yes, we should probably also save 
window size and position when the window is closed, in addition to all the other 
places we already save it. Steps slightly different from those you gave above 
show the problem on my build: launch Mozilla, open a second browser window, 
(optionally move it), close it, then close the first window (exiting Mozilla) 
without moving it. On relaunch, the first window opens at the last position of 
the second window, not the first (and last) window.
  I'm not sure what I want to do about this. I can make it work, but I have to 
remove several speed optimizations. I need to at least put this on the bench and 
see how much it slows down window moving.
Ever confirmed: true
Keywords: helpwanted
Target Milestone: --- → mozilla1.0

Comment 8

16 years ago
Created attachment 40189 [details] [diff] [review]
fixes problem but reverts several speed optimizations. wants some more thought.

Comment 9

16 years ago
Thanks, dan.  Is there any way for you to tell if the current window is the
"last" remaining one, and only save the position then?  It wouldn't save too
much on speed, but it should help a little.

Comment 10

16 years ago
switching to toolkit and jrgm
Component: XP Apps → XP Toolkit/Widgets
QA Contact: claudius → jrgm


16 years ago
Blocks: 89740

Comment 11

16 years ago
*** Bug 96009 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
Alright. This bug has been driving me bonkers for weeks now. Time to pull in its 
milestone. I guess there's nothing to be done for it but to give up on the 
performance gains, such as they were, from bug 79060 / bug 70283. (Some of those 
optimizations can be kept, but nothing important. Here are times spent in 
PersistPositionAndSize for a few choice tasks. "original" is the numbers reported 
in the "old" column in bug 79060, "current" is current times, "new" will be times 
after the patch has been applied, "dt" is the time gain or loss from original to 
new and then from current to new:

                             original current   new        dt
move Navigator window          1.088   1.214   1.173    +8%/  -3%
activate Navigator window      1.892   0.290   2.061    +9%/+611%
new Open Web Location Dialog   2.168   0.473   2.094    -3%/+340%
new JS Alert                   0.457   0.377   0.380     0 / -17%

So we'll pretty much be reverting to the pre-optimized times, with a small gain 
seen in windows which persist no state at all. Again keep in mind these numbers 
are in milliseconds (though on a pretty fast machine; a 733 MHz P4), so it's not 
actually such a big time hit. What-you-gonna-do. The optimization was bad.
Target Milestone: mozilla1.0 → mozilla0.9.5

Comment 13

16 years ago
Created attachment 48357 [details] [diff] [review]
combined fix for this bug and bug 96475

Comment 14

16 years ago
Sorry about the combined patch. They both affect the same file(s), they both 
address similar problems, and they're both in my local tree right now.

Comment 15

16 years ago
Danm... thank you, thank you! :)  This has been driving me nuts as well, but I
didn't want to bug you about it.

Comment 16

16 years ago
danm assures me he's going to look into the possibly extraneous
StoreBoundsToXUL() call in the top of the nsWebShellWindow.cpp diff ;-), r=pchen

Comment 17

16 years ago
Danm, thank you very much for fixing this bug, the comment of Warner Young
passes exactly for me too.

Comment 18

16 years ago
Glad to be of service, if only occasionally.

The patch is in. Note that I didn't check in the change to nsWebShellWindow; the 
one that explicitly saved a window's state when it's closed. (And therefore the 
redundant call of StoreBoundsToXUL that Paul mentioned above was not checked in.) 
That part seems unnecessary, since the rest of the patch restores state 
persistence as a window is activated.

So though I've omitted the part that explicitly addressed this bug, I claim the 
bug is fixed implicitly. Reopen it, of course, if you find otherwise.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 19

16 years ago
danm, sorry.  I'm reopening this, as I still see the browser start in the wrong
position sometimes.  Not always, and I haven't figured out what causes it yet. 
But I always close the main (initial) window last, and that never moves, so I
believe what I'm seeing if this bug.
Resolution: FIXED → ---

Comment 20

16 years ago
I never see the problem any more; it always works for me. I'm re-closing as a way 
of encouraging steps to reproduce.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 21

16 years ago
Reopening because although the patch is good in everyday use there is a problem
if your last action is resizing the browser window (no moving of the window
after that).

Reproducible: always. Steps to reproduce: 1. For better visibility (not
necessary) stretch the top, right and bottom border (but not the left border) of
the browser window aproximately to the border of the screen. 2. Move the window
a bit around the screen but place it again on that last position. 3. Close the
window. 4. Restart Mozilla (it's OK if Quick Launch is enabled, that doesn't
matter). The window is at the correct position again. 5. Resize it on the left
side for about one inch to the left. 6. Close the window and restart Mozilla
again. Actual result: The window is positioned wrong, the right side goes out of
the screen for about the amount of space which was added to the left in the step
before. Expected: The window is on the same position on which it was last before

Build: 2001091203. I'm not absolutely sure if this occurred in older builds
after this bug was resolved.
Resolution: FIXED → ---

Comment 22

16 years ago
Ah. Short version of the above steps: resize the window by dragging the top or 
left borders. Quit and relaunch. The first window opened is sized correctly, but 
its position is incorrect; that is, unchanged and it should have been changed.

When a border is dragged, Windows doesn't send us a WM_MOVE event; only 
WM_WINDOWPOSCHANGED. The current WM_WINDOWPOSCHANGED handler makes note of only 
the new size, not the new position, assuming a WM_MOVE is on the way. I have to 
tread a little lightly fixing this: mixing up the size and position persisting 
code can cause infinite loops if you're not careful.

Anyway, I understand. Thanks for pointing that out. I'm going to call this a 
minor problem and it'll probably end up getting pushed off a milestone or two.
Priority: -- → P4

Comment 23

16 years ago
*** Bug 100236 has been marked as a duplicate of this bug. ***


16 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6


16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7


16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8


16 years ago
Target Milestone: mozilla0.9.8 → ---


16 years ago
Target Milestone: --- → Future

Comment 24

15 years ago
Windows 2000 Professional. Mozilla 1.1b 2002072514

Open Mozilla, the browser window opens on the left side of my screen, the status
bar on the bottom is below the task bar level, which is a double high task bar.
Move the browser window to the left with the bottom resting on the top edge of
the task bar then close the browser, when I reopen it the browser window is
again on the left with the status bar covered by the task bar at the bottom of
my screen.
This worked fine in 1.0, stopped working correctly in 1.1a and 1.1b

Comment 25

15 years ago
re comment 24: If you use QuickLaunch this may rather be bug 139142 (QuickLaunch
places first window too low on screen (below the windows toolbar).

Comment 26

15 years ago
I still get this in 1.2b build 2002091904, win98.  The supposed speed
optimizations are meaningless if I lose 5-7 SECONDS always repositioning the
window where I want it, vs the 1-2 MILLIseconds saved by the optimization. 

At least from reading bug 166226, I figured out that it goes away if quicklaunch
is disabled.  whew.  It was starting to irritate me...  Basically, I could see
absolutely no way to get the initial window to appear anywhere other than 0,30.
 Since I prefer the window on the right side of the screen, I was having to move
it evvverryyy sinnngle tiiiime.  I would think that most users want a consistent
and personalized browsing experience - ie, the window where they left it...

(I don't think this is part of 139142:  The window wasn't coming up lower each
time for me, just ALWAYS in 0,30.)

Comment 27

14 years ago
The bug is back in it's former glory in Mozilla 1.5b running on XP.

Comment 28

14 years ago
Actually, I'm not sure it's caused by the same thing, so I filed a new bug on it
(bug 210689) for this recent regression.

Comment 29

14 years ago
*** Bug 203590 has been marked as a duplicate of this bug. ***

Comment 30

14 years ago
The "fixes problem but reverts speed optimizations" patch was checked in
September 2001. See bug 89740. (Except for the line that saved attributes every
time the window was closed, regardless of whether they'd changed. That shouldn't
be necessary, anyway.) And the speed optimization hasn't been checked back in.

The problem reappeared in all its, and there's no damn apostrophe in that word,
glory in June 2003, but was fixed again September 2003. See bug 210689, opened
by Warner in comment 28.

That leaves QuickLaunch bug 166226 (still open) and the curious bug 203590, once
duplicated against this bug but now also still open. Is there any reason why I
shouldn't close this bug?

Comment 31

14 years ago
Danm, IMHO, this bug should have been closed, fixed a long time ago.  If
anything similar happens again, a new bug should be filed anyway.

Comment 32

14 years ago
Oh. It helps if I read my own comments. This bug was fixed September 2001 but
was left open because of the issue remaining in comment 22. Now it's just
confusing people and attracting unwelcome attention. I'm closing this one,
milestone 0.9.5, which is true enough, and opening a new bug 221625 for the
comment 22 thing.

PS I'm almost afraid to say this but on the 6th I checked in some changes to the
window persistence code. A new bug is called for if anyone notices any problems.
Last Resolved: 16 years ago14 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla0.9.5

Comment 33

13 years ago
*** Bug 97416 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.