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.
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 likeable.
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 instance. 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.
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 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 closing. 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 my screen. 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. ***