User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030723 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030723 After changing the User Name through Server Settings there's a possibility that an account added later will collide, even though there's a difference. This happens when the username & hostname from before the change are the user name & server name for the new account. (This happens because of the way changes are made on the fly) Reproducible: Always Steps to Reproduce: 1. Make a new email account where the user name is eg. name1 and the server name (Incoming Server) is eg. pop3server 2. Go to server settings for this account and change name1 into name2 (moz gives a "settings updated" popup) 3. Add another account with user name name1 and server name pop3server Actual Results: Mozilla doesn't complain, but the new account is not listed anywhere. Expected Results: Mozilla should have added and listed the account so the user can access it. The same happens when the server name is changed instead of the user name. Here's what I think is going on: In prefs.js the user name is stored in user_pref("mail.server.server1.userName", "name1"); When the settings are changed later on through server settings mozilla adds user_pref("mail.server.server1.realuserName", "name2"); NB It doesn't change mail.server.server1.userName When an account is added later with user_pref("mail.server.server2.userName", "name1"); and with the same mail.server.server2.hostname as server1 Mozilla will think they're duplicates and fail to display the 2nd account (since server1.userName == server2.userName and server1.hostname == server2.hostname even though there's a server1.realuserName), although Mozilla added the account without complaining One possible solution might be (This would have to happen on exit or startup, whenever it's safe) 1. Detect if there's a .realUserName or .realHostName entry 2. Move the entry (eg. name2) into .userName or .hostname respectively 3. Remove the .realUserName or .realHostName entry This way mozilla doesn't run into problems with the obsolete .userName entry in the way described above.

This bug still exists, and real world users who don't even know prefs.js exists have run into it. Someone who asked for help with mail account problems was the reason I found out about this bug and submitted it in the first place. Anyway, bug 131176 comment #3 (the first half anyway) describes the behaviour of this bug, I hope that one doesn't get another 3 years of neglect. *** This bug has been marked as a duplicate of 131176 ***