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*
Results: browser appears in the position of the last *opened* browser window.
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
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.
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?
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?
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.
Created attachment 40189 [details] [diff] [review]
fixes problem but reverts several speed optimizations. wants some more thought.
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.
switching to toolkit and jrgm
*** Bug 96009 has been marked as a duplicate of this bug. ***
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.
Created attachment 48357 [details] [diff] [review]
combined fix for this bug and bug 96475
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.
Danm... thank you, thank you! :) This has been driving me nuts as well, but I
didn't want to bug you about it.
danm assures me he's going to look into the possibly extraneous
StoreBoundsToXUL() call in the top of the nsWebShellWindow.cpp diff ;-), r=pchen
Danm, thank you very much for fixing this bug, the comment of Warner Young
passes exactly for me too.
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.
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.
I never see the problem any more; it always works for me. I'm re-closing as a way
of encouraging steps to reproduce.
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
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.
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.
*** Bug 100236 has been marked as a duplicate of this bug. ***
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
This worked fine in 1.0, stopped working correctly in 1.1a and 1.1b
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).
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.)
The bug is back in it's former glory in Mozilla 1.5b running on XP.
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.
*** Bug 203590 has been marked as a duplicate of this bug. ***
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?
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.
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.
*** Bug 97416 has been marked as a duplicate of this bug. ***