Build 2002031103, Win2k. Some really weird shit is going on here. When I update the mail server and/or mail user name, Account Manager updates mail.server.serverX.realhostname and .realuserName in prefs.js instead of mail.server.serverX.hostname and .userName. I just discovered that my mail account seems to be corrupted (it refuses to save copies of outgoing mails in Sent -- probably a known bug or something). No problem, I thought, I'll just delete the account and recreate it. On second thought, no, I don't want to lose the email that I have in that account. Okay, I'll just turn off the automatic message checking for that account and create a new account which I can start using instead, then. So I tried to do so. But I was told that there was already another account with the same server and user name. Okay then, back to the other account and change the user name to something random, and then try again. But no, I wasn't allowed to do so, as the userName pref still contained my real user name. If the seperate hostname/userName and realhostname/realuserName prefs are needed for some reason, at least make it so that they don't result in corrupting your mail account information. I'm setting severity to critical as this could prevent users from being able to check their mail.

Two corrections: 1) "But no, I wasn't allowed to do so, as the userName pref still contained my real user name" should have been "But no, I still wasn't allowed to create the new account, as the [...etc.]". 2) "I just discovered that my mail account seems to be corrupted" and "so that they don't result in corrupting your mail account information" -- I just have specified more clearly that these two "corruptions" is not related.

If you change the server and user names the new values will be stored in realhostname and realuserName prefs. This is by design and see bug 14295 for more info. realhostname and realuserName are used in making connection to the (new) server, and hostname and userName are used for internal url, directory purpose. > But no, I wasn't allowed to do so, as the userName pref still contained my real > user name. > Can you be more specific on this? For example, do you get an error dialog and if so can you spell it out? What are the old and new username did you try to change? etc. More info will help us to resolve the problem quickly. Thanks.

Sorry for being such a terrible bug reporter -- that happens some times. :-) Okay, so here's some steps to reproduce: First, I create a blank profile. Then I add this mail account: Host name: first.server User name: username-for-first-server The relevant lines which are added to prefs.js are these: user_pref("mail.server.server1.hostname", "first.server"); user_pref("mail.server.server1.userName", "username-for-first-server"); Now I go to account settings and change the host name to second.server and the username to username-for-second-server. The relevant lines in prefs.js now look like this: user_pref("mail.server.server1.hostname", "first.server"); user_pref("mail.server.server1.realhostname", "second.server"); user_pref("mail.server.server1.realuserName", "username-for-second-server"); user_pref("mail.server.server1.userName", "username-for-first-server"); Then I go to account settings again and add a new account, with server first.server and username username-for-first-server. Naturally, I assume that this server/username combination is not used anywhere anymore, since I just changed the server and username for the first account. It now tells me that the account has been added, but it doesn't show up in the account list! Not in the server pane, not in account manager -- not anywhere! But my prefs.js now contain some more lines: user_pref("mail.server.server3.hostname", "first.server"); user_pref("mail.server.server3.userName", "username-for-first-server"); If I then try to add that account again, I get the following error message: "A mail or newsgroup account with the same user name and server name already exists. Click Back and enter a different server name, or click Cancel" But that is, of course, the correct behavior, as the account already exists. The problem here is that the account isn't displayed. My opinion is that the current design is just broken. I certanly do *not* want any information about the old server/username stored in prefs.js if I change it to something new, even if it is only used internally. In some scenarios, that might actually be a severe privacy issue. Imagine if the CIA used Mozilla as their mail client on a computer in some top-secret place, and that place gets some new computers and all the old computers are moved to another department. There, they don't bother to delete the mail account, they just change the server name and user name. And now the people in that other, publically accessible department will be able to see the name of CIA's internal top-secret mail server. Okay, I know that the CIA would completely wipe all disks a million times before allowing ANY computer department to leave their top-secret labs, but you get the idea. In addition, this can be very confusing if you're going through prefs.js or even just looking at the Local Directory field in account manager and suddenly notice that an old server/username which you haven't used for years is suddenly still mentioned somewhere. For internal urls, why not just generate random garbage data or just use names like "server1", "server2", etc? That would be a much better solution IMO. A general principle that I try to follow when I'm programming is that I never ever use a username or something like that as a file name/directory name/whatever if I'm not renaming that file/dir/whatever if the user changes the user name. I find Moz's current behavior Bad. Changing it to use strings not related to the server name/username for internal strings will probably also fix this bug, BTW. I'm really sorry for saying this, as I now how fscking annoying it is to hear stupid users say that they think that this or that bug should be fixed ASAP, but I think that this bug should be fixed ASAP. :-)

OK, I see the problem. This used to work I think. Will investigate.

Nominating nsbeta1.

Seth, the backend seems to be doing the right thing (ie, it returns "Account Not Found" when you add back the account that was previously changed/modified) so I wonder if this is caused by the old account info still exists in RDF. In other words, the problem is that the backend says that it's ok to create the account but the front-end does not display the new account in the account list.

Forgot to cc Seth.

Discussed at Mail News bug meeting with Engineering, QA Mktng and PjM. Decided to minus this bug.

For the record: This bug makes it impossible to change the incoming server name and username of a POP account without FUBARing your mail account information and most likely losing your old mails unless you know how to edit prefs.js by hand.

Renominating for nsbeta1; please see comment 9.

Discussed in Mail News bug meeting. Decided to minus this bug.

mass re-assign.

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

Jonas Jørgensen's <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=131176#c3">comment</a> sums up the issue pretty well. I can confirm this bug on Mac OS X. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=274027">Bug 274027</a> seems related to this.

Tb version of Comment #3 is Bug 303542.

For next bug summary. > realhostname and realuserName is updated instead of hostname and userName If your claim is hostname and userName should be updated instead of realhostname and realuserName, this bug is INVALID, because it's design and "updating of realhostname and realuserName" it self is working as designed. If your comment #3 is real problem, I think DUPIng this bug to Bug 303542 is better after changing Bug 303542 to mailNews Core bug, because Bug 303542 has better bug summary.

Following is copy of mail from bug opener to me on 6, Mar, 2009. > > Tb version of Comment #3 is Bug 303542. > That would be the tb version of the whole bug then, not only of comment 3... > comment 3 was just my attempt to clarify what I meant in the original description, > which wasn't very good... :-)

Can this be resolved in any way? This looks to be OK by design. Maybe there are more concrete bug filed about how to mitigate the user confusion.