I have seen this regress a couple of weeks ago. To reproduce: 1. Launch Mozilla (Navigator window is opened in the same state than when it was last closed) 2. Open MailNews main window - it's not maximised and has an arbitrary size and position. 3. Maximize or move or resize Mail Window 4. Close Mail Window 5. Open MailNews main window again - It is in the same arbitrary state than after (2.) - the state we had left it in wasn't restored. Message Composition Window and Message Window exhibit the same problem.

Hmmm.. I was wrong with the navigator window, it's not remembering its state in this profile, it always starts up in the same state - the only difference is, it starts in maximized state. Something rotten in my profile and Mozilla fails to remember state of windows after closing them. I've noticed that in a different user's profile (my system's root's profile) the state of windows is properly preserved after closing. However this in not a matter of file permissions - I _do_ have write permissions to all the files in my profile dir. In root's prefs.js, I've spotted some rows that looked promising and I copied them to my unprivileged user's prefs.js: user_pref("mail.compose.win_height", "0"); user_pref("mail.compose.win_width", "0"); user_pref("mail.default_fcc", ""); user_pref("mail.folder.win_height", "0"); user_pref("mail.folder.win_width", "0"); user_pref("mail.msg.win_height", "0"); user_pref("mail.msg.win_width", "0"); user_pref("mail.thread.win_height", "0"); user_pref("mail.thread.win_width", "0"); However, this didn't help. I tried to change all occurences of "0" to 0 (Because I suspected that bug 113482 might spoil those options in prefs.js by enclosing them in quotations). Nothing changed. Mozilla doesn't seem to touch those settings, because after I mess with windows' sizes/positions and close Mozilla they are left unchanged (only that Mozilla sorts all rows in prefs.js on exit, so those options I had added are placed in different places around prefs.js)

BTW, I were trying to find information about those prefs on http://www.mozilla.org, but couldn't locate any single page that would explain contents of prefs.js. Does such page even exist? If it doesn't, or isn't offered publicly, then it should... Lots of bug testing would be easier with some reference documentation about the prefs.

I just found out that deleting localstore.rdf in my profile dir solves the problem. I'll attach the previous localstore.rdf that was causing problems so that it may be analysed why it had gone wrong in the first place.

This localstore.rdf is a part of a profile I migrated from Windows 2000 (you can see it contains Windows style paths). Probably those paths caused problems I described. It seems that Mozilla doesn't invalidate those entries in localstore.rdf although directories listed there clearly don't exist anymore.

Updating multiple bugs. This is a valid UI issue. Would be nice to have it fixed if time allows.

reassigning to ssu and cc'ing varada. It sounds like there may have been some corruption in the localstore.rdf I don't think this is a mail bug.

Hmm, that localstore.rdf of mine was moved from win32 to linux. So maybe this is a dupe of bug 7067 or bug 66259? The problem here seems to be that localstore.rdf isn't portable...

Ugh, no progress on this? :( I only use the Mozilla mailer (I use Galeon/Gecko as my browser), and I launch it with "mozilla -mail"... it keeps launching at a similar position as Navigator.

*** Bug 138878 has been marked as a duplicate of this bug. ***

*** Bug 177468 has been marked as a duplicate of this bug. ***

per comment 8, thanks Aleksander. *** This bug has been marked as a duplicate of 66259 ***