Closed Bug 392360 Opened 18 years ago Closed 15 years ago

Password Manager Displays <> Instead of Actual User ID

Categories

(SeaMonkey :: Passwords & Permissions, defect)

SeaMonkey 1.1 Branch
x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: david, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Mnenhy/0.7.5.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 When I select [Tools > Password Manager > Manage Stored Passwords] from the menu bar, the entry for the cited URL shows <> for the User Name. However, when I actually go to the cited URL, the correct User Name is entered. Somehow, I wound up with two entries in Password Manager for this URL, both of which displayed <> for the User Name. Then, the selection popup to choose an entry also showed <> for both entries. Actually, the two entries were identical. No matter which one I chose from the popup, the correct User Name appeared in the Web page's logon. I have seen this problem only with Password Manager entries for this one Web site. For this site, this is a consistent problem. Reproducible: Always
I did some additional investigation of this problem. To see the problem, do the following: 1. Establish an account at the cited Web page, entering the user ID and password into the Password Manager database during the initial login. 2. Logout from the Web site and go to any other Web page. 3. Select the cited Web page. When the page finishes loading, the user ID and password will be inserted in the "Member Login" by Password Manager. Select the "Sign In" button. 4. Password Manager's Confirm popup will appear with "Yes", "Never for this site", and "No" buttons. Selecting the "Yes" button adds an extra entry in the Password Manager database with "<>" as the user ID. Note that, on a later login to the site, the redundant database entries for the cited page cause a selection list of user IDs to be displayed by Password Manager. All entries in the selection list have "<>" as the user ID. Selecting any one of them causes Password Manager to enter the actual user ID in the page's "Member Login". Viewing the Password Manager database, however, shows one entry with the actual user ID and the redundant entries with "<>". I also established an account at <http://www.losangelesgasprices.com/> with the same user ID and password as at the cited page. When Password Manager saved the user ID and password for this Los Angeles site, the user ID appears as "<>". This was the ONLY entry in the Password Manager database display for the Los Angeles page. This bug report may apply to all the various sites operated by gasbuddy.com, which has over a dozen sites for counties in California plus sites in most other states and Canadian provinces. I see two problems in Password Manager: (1) the use of "<>" as a user ID when that is not the real user ID and (2) the appearance of the Confirm popup immediately after Password Manager inserts the user ID and password from its database into login fields. Yes, the gasbuddy.com sites might contain errors. However, Password Manager should not exhibit this behavior under any Web site errors.
Password Manager of Seamonkey saves (A) field_name/data for user_id, (B) field_name/data for password, (C) field_name/data for other fields. If (A) has filed_name such as "user_id" and (B) is <input type=password> and one of (C) has filed_name such as "signin_id", and if filed_data for (A) is null, and if server uses the one of (C) for login (ignores (A), or uses (A) for other purpose), explained phenomenon possibly occurs. I guess that multiple password manager entries are created, if field which Password Manager considers as "user_id" filed contains null. > SeaMonkey/1.1.4 When Seamonkey 1.x, password manager data can be seen by text editor. Check content of <random_number>.s file in profile directory. ( pointed by user_pref("signon.SignonFileName", "xxxxxx.s"); ) ( Disable of "Master Password" is perhaps required to see content. ) When Password Manager of Firefox (1.5, 2.x, Trunk), only (A) & (B) are saved, so (C) is never be saved. (This is already reported issue, but possibly WONTFIX) Will user ID & password save/fill for the site work as expected with Firefox?
When the site you put in URL: of this bug ( http://www.venturagasprices.com/ ), page has only one <form name="Form1">, and many text fileds are defined in the single form, although single password filed only. You can see it by View/Source and following code in URL bar. > javascript:var%20m='';var%20f=document.forms['Form1'];for(var%20x=0;x<f.length;x++){var%20e=f.elements[x];if(e.type=='text'&&e.name!=''){m+=e.name+'\n'}if(e.type=='password'&&e.name!=''){m+='PWD%20:%20'+e.name+'\n'}}alert(m); I dont't know which text filed is used by Password Manager as "user ID" field you say. I don't know whether text filed just before password field is considered by Password Manager as "user ID" filed, or not.
Can you reproduce with SeaMonkey v1.1.9 ? Can you reproduce with SeaMonkey v2.0a1pre ?
Assignee: dveditz → nobody
Version: unspecified → SeaMonkey 1.1 Branch
Yes, this remains a problem in SeaMonkey 1.1.9. With a dial-up connection, I am reluctant to download nightlies, alphas, and betas. If you really think this is fixed by a specific, identifiable change in v2.0a1pre (or later), I will download it for testing.
Whiteboard: [obsoleted when bug 588421 lands]
Should be fixed by the move to the toolkit manager with SeaMonkey 2.0. Please test with the latest SeaMonkey 2.0.10.
Whiteboard: [obsoleted when bug 588421 lands] → [CLOSEME 2011-02-01 WFM]
The cited Web site was redesigned and can no longer be used to demonstrate or test this bug. I have not seen this problem elsewhere recently.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Whiteboard: [CLOSEME 2011-02-01 WFM]
You need to log in before you can comment on or make changes to this bug.