213598 - changing user or server name in server settings allows for later collision

Status: RESOLVED DUPLICATE of bug 131176

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[Ferdinand]

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.

Comment 1

[Ferdinand]

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 ***