203590 - persistent window position changed unexpectedly after Mozilla crashed

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Konrad]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Like most I like to open the windows always at the same position.

Mozilla Browser does if you switch off Quick Launch, see bug 166226.
BTW To me it looks Bugs 97416 and 86955 are old, dupe of or replaced by 166226.

But there is another case, if Mozilla does crash it does start next time at
another position.

Here its always where usually the 2nd Browser window would be positioned. But
maybe that depends how many windows were open, here its usually 3.


Reproducible: Always

Steps to Reproduce:
1. start Mozilla Browser with Quick Launch disabled
2. make Mozilla crash (evil)
3. start Mozilla Browser again

Actual Results:  
Browser windows starts at another position.

Expected Results:  
Browser window should start at the usual position.

Comment 1

[Jon Henry]

Konrad, are you still having problems with Mozilla not remembering its window
position in recent builds? I'm a little unclear as to what the problem is...if
Mozilla does not remember its position after a crash, that is probably to be
expected. It saves its window position when shutting down, so naturally crashing
would "skip" that process and the windows would be at the position they were
last saved in the next time you start up Mozilla. Or is there another problem
here that I misunderstand? Thanks for any new information.

Comment 2

[Konrad]

the behaviour is still the same with Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.5) Gecko/20030916

Mozilla does save a new startup window position already when opening a new
window. Otherwise it would not start at another position after a crash.

Likely Mozilla does save it again when shutting down. You need to make sure to
end Mozilla before turning off or rebooting the system and close the first
window last, otherwise the start position is changed too. Imho Mozilla shouldn´t
force users to this workarounds.

I guess this behaviour of Mozilla is the reason for changing window position
with Quicklaunch - bug 166226 - since you cannot manually make sure Mozilla
stores the original startup position as new startup position again.

What I would like most is if Mozilla does change the window position only if you
manually move the first window.
The position of 2nd and following windows isn´t choosen by the user but by
Mozilla. So why make this a new startup position ?

Comment 3

[Jon Henry]

Hmm, perhaps this is a dupe of bug 86955? Could you take a look at that and see
whether the symptoms of the problem you're having are the same? Thanks.

Comment 4

[Konrad]

Bug 86955 was fixed, reinvented recently but fixed again. Also it contains a 2nd
bug.

But there is a interesting comment from "Dan M", saying windows position are
saved at several places.
This might be the reason for the problem, too much of a good thing. Only save
when the user wants Mozilla does start next session at a different position.

Comment 5

[Jon Henry]

For now, I'm going to mark this as a duplicate of bug 86955, but feel free to
reopen this if you disagree. They do look similar to me.

*** This bug has been marked as a duplicate of 86955 ***

Comment 6

[Konrad]

sorry it isn´t a duplicate, bug 86955 is fixed
there is a workaround, saving the window position when closing windows

this bug isn´t fixed, the workaround will not work if Mozilla does crash:
if you did use more than one window Mozilla will start at another position
despite the user didn´t change any positions

but I guess both bugs have something in common, are the result of the same
problem: Mozilla does save startup windows positions after Mozilla itself - but
not the user - did change a window position

after some thinking for me this looks very obvious, doesn´t it ?

Comment 7

[Jon Henry]

That bug is marked assigned, not fixed, which means someone is working on it. I
guess I don't understand how the problem you're describing is different from the
one in that bug. When you crash Mozilla and then restart it, where is the window
opening, and where should it be opening, exactly? Is it opening in a random
place, or are you moving the window, then crashing it? Do you always want the
first window to open in the same place, regardless of where other windows got
moved to? If that's the case, then this is a dupe of bug 86955, since the
reporter states that "I want my (non-maximized) browser window to open in the
same place each time I start Mozilla".

I don't mean to sound upset or anything, I just want to understand why this
problem is different from what's described in the other bug.

Comment 8

[Dan M]

I don't have much guilt about really minor unpredictable behaviour after a
crash. It's alright when you don't crash, isn't it? It doesn't do that a lot,
does it?

I simulated this situation by:
  1) launch mozilla. first (browser) window opens where it should.
  2) open a second browser window, which opens offset from the first.
  2a) optionally move that second browser window so you know for certain
      it's trying to save its new position.
  3) kill the process.

After relaunching, the first window opened where the first window opened in (1)
above, which seems to be what you're asking for. I'm saying I can't reproduce
this. I did just get through smacking around the window persistence code. But I
get this same behaviour in my new build and in the older Mozilla 1.4.

But if I understand correctly, I think you're asking that the first window
always open in the same place, regardless of what other windows you've opened.
It's an interesting idea. It's the opposite of a many-years-old design decision,
and I'm talking Navigator 4 and probably earlier, to open the next window where
you left off in your last session.

That at least has the benefit that it uses an intuitive user gesture.
Remembering the position only of the first window opened is too hidden. I feel
confident saying that users will be confused when window position persistence is
tied to only one of their windows, an unmarked one with no apparent special status.

Have I misunderstood? Finger hovering over the "won't fix" button...

Comment 9

[Dan M]

...and landing. My understanding is that this is a request for behaviour that,
while probably an improvement in the case described, would necessarily be a
liability in the majority of cases or require a clunky preference of some kind.
(See comment 8.) Closing.

Comment 10

[Konrad]

Sorry you are upset but you wrote "but feel free to
reopen this if you disagree" and thats what I did. How should I know its
something better not to do ? Anyway any contribution in Bugzilla seems senseless
to me, 90% of the bugs are open since long and never get fixed.
Seems it doesn´t matter what I write, its just ignored, maybe my english is just
too bad. Back to topic:

1. bug 86955 is fixed so this here cannot be a duplicate since this isn´t fixed

2. If I share statements of other people writing other bugs this doesn´t say all
this bugs are duplicates (but this says you tend to ignore the preferences of
the users). All bugs use letters A-z, so all are likely duplicates ? :P scnr

3. Mozilla does crash often here, sometimes even repeatedly when loading and I
have to reboot. If it does crash after some time of use - at least 3 windwos and
several tabs in it - it starts at a different position, usually that of the 2nd
window - despite I didn´t change any window position.
I doubt very much this a wanted behaviour, this so called "many-years-old design
decision". At least in the GUIs I know its not usual to change user settings if
the user didn´t change them.

4. This behaviour proofs the window position is changed by Mozilla despite the
user didn´t change any position, didn´t move any window.
From my nearly 20 years experience in bug hunting, reading many other bug
reports, the testing described there and my own tests I´m sure this is the
reason for a lot of problems in this area.

bye

Comment 11

[Dan M]

In my testing (comment 8) peristent window position didn't change, even after
opening a new window, in a new position. The new window did (i'm certain)
attempt to save its position as the new persistent one, it just didn't take.
Whether the first window after re-launch actually changes position is very
likely a matter of whether the change happened to have been flushed to disk
before the crash.

Sorry to hear Mozilla crashes on you so often.

Also, apologies for all the open bugs in the database. Perhaps it would be more
honest to just go close a zillion or two of them but it's probably wiser not to
throw away the distinction between bugs that are dead, dead, dead, and bugs that
could be revisited some day.

Konrad, my reading of this bug leads me to agree with you that it's not a
duplicate. You have what I'd term a legitimate concern. I closed the bug because
I think no proper fix exists.

Mozilla currently, and has always as far as I know, opened its next window where
the last window was, with some adjustment. I think it's a widely appreciated
feature that's taken for granted by a majority of users. To address your
concern, we'd have to make a change in that behaviour and that's ground I fear
to tread.

I can think of only three possibilities, (one more than I outlined in comment 8):

1) Tie position persistence to only one special window, instead of all of them.
Perhaps only the first window opened, or the oldest window currently open, or
the last window closed.
2) Never persist window position automatically. Add instead a command to take a
size and position snapshot at user's discretion.
3) Re-architect position persistence so that it isn't flushed to disk except
when the program closes normally.

(1) sucks. It's too undiscoverable and too surprising. (2) isn't awful but I
predict a fiery reception for anyone attempting to champion its cause. (3) is
kind of obvious though I missed it the first time. It really would be a
re-architecture, though. Position persistence is tied to a bunch of automated
subsystems. Breaking it loose would be a non-trivial rewrite which in my opinion
isn't justified by the circumstances of this bug, which I really hope are an
uncommon exception.

Again I agree, you've pointed out a genuine issue. I just believe it can't be
fixed practically. I'll ask around a bit, though, just to make sure I haven't
closed this issue down unreasonably.

Comment 12

[Dan M]

Things become clearer later. Actually, a small re-architecture, without touching
the lower-level things I mentioned above, would improve window status
persistence and also fix the problem mentioned in this bug. The trick is to not
persist status to localstore until the last window is closed. Yes, that's option
(1) from comment 11 which sucks. But it doesn't suck if persistence only matters
between sessions; that is, if new windows after the first one key off older
windows, rather than using the persistent data store.

This may not work very well on unix, where the current architecture actually
guarantees more accuracy than would working with the most recent window. We
don't have a good idea of which window is the most recent on unix.

Still, this is probably workable and should be an overall improvement, not just
for the reason mentioned earlier in this bug. Reopening.

Comment 13

[Dan M]

.

Comment 14

[Dan M]

Attachment: rewrite of persistent window attributes

This patch should fix the problem mentioned in this bug. It's a rewrite of
persistent window attributes. The current code relies on the persistent data
store to always be correct and goes to some length to assure that it is. With
this patch it would use the persistent data store only if there's no topmost
window of the same type to use instead.

This has several advantages. It does away with the persistence timer, which has
been problematic. No persistent data are flushed to disk until the last window
(of a given type) has been closed, thus knocking this bug down.

Notes:

The patch for nsXULWindow.cpp is a diff -bu.

Included is yet another rewrite of StaggerPosition. Keying from the topmost
window made the current algorithm wonky. This version is much simpler in
execution and in intent: it doesn't even try to assure that a window is not
placed exactly on top of any extant window, but only the topmost one. It's also
better about picking a direction to stagger. This version seems sufficient, and
faster.

This patch may be problematic on gtk builds, where record keeping of the most
recently changed persistent attribute is better than record keeping of which
window is topmost. However I think it'll be OK (wouldn't hurt to check it,
which is inconvenient for me to do) and this problem is mitigated by the
coincidence that gtk builds also don't care about any of the persistent
attributes except size.

Comment 15

[Jon Henry]

I think by now it's fair to mark this as new and move it out of Browser-General,
it sort of fell off my radar for a while. Is this patch still good/desirable?

Comment 16

[Dan M]

The patch in this bug is still a good thing to do. But it has a problem with
maximized and minimized windows that the old algorithm doesn't. See blocking bug
231843.

Comment 17

[rduncan]

I cannot get Mozilla Firefox to stay at a particular place on my desktop.  After the new version loaded, it lost this feature.  In addition, I lost my bookmarks, again, during this upgrade.  How can I avoid from this happening.  I do like Firefox but I've been burn 3 times losing my bookmarks.

Lastly the bookmarks toolbar always shows up every time I invoke Firefox.  I changed the setting for this and of course it removes it for that session but once you close Firefox and reopen it, the bookmark toolbar reappears.

[e-mail]