Closed Bug 92532 Opened 23 years ago Closed 23 years ago

password input values still sometimes stored in session history

Categories

(Core :: DOM: Navigation, defect)

defect
Not set
major

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: bbaetz, Assigned: pollmann)

Details

While testing builds (on all 3 platforms), I noticed that the fix for bug 65947 isn't complete, and we still appear to be saving password fields in the following edge case: 1. Have a username/password stored in password manager for a particular page. 2. Go to that page, and overwrite the stored username/password with another. Use a password with a different number of characters (so that you cna verify this). 3. Submit the form. 4. Select "No" from teh password manager dialog which appears. 4. Click back 5. Notice that the password field is filled in with something the length of the new password, not that of the original (ie its not being pulled from the password manager). The user name is the new one as well. This doesn't happen if a form has autocomplete="no" (so we don't use the password manager), so I don't think it will be an issue with the particular server in bug 65947. This also doesn't happen on a simple test page I cooked up, but it does happen on both the bugzilla and bugscape pages, as well as one of Ian's (not sure of the url though). Ian?
> 5. Notice that the password field is filled in with something the length of > the new password, not that of the original (ie its not being pulled from the > password manager). The user name is the new one as well. That's not what I'm observing. Instead I'm seeing the password being pulled from the password manager (as it should be) but the username is the new one. So what it looks like is happening is that password manager is kicking in (as it should) but then someone is coming along and reinserting the new username, probably from the session history. Reassigning.
Component: Password Manager → History: Session
morse: Hmm. I'll look into that tomorrow, but both ian and I were seeing that happen. Note that (from bug 65947), the expected behaviour is that the form elements are overriddent from session history as usual, but the password field isn't. Why are we calling the password manager at all if we're going to overwrite the values with session history, anyway?
Are you guys both testing the same page? :)
I used a simple test page of my own and also used bugzilla. baetz reported that he used bugzilla so, yes, we are using the same test page.
Thought that I reassinged this yesterday but apparently all I did was change the component. So now I'm really reassigning.
Assignee: morse → radha
QA Contact: tpreston → claudius
Yeah, I can't reproduce it now. Sigh. Interestingly, if I don't wait for the next page to complete loading before pressing back, then the username field is grabbed from the password manager, not session history.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
I also can not reproduce this. Marking WORKSFORME, but please reopen if you can find a way to reproduce it!
Reopening to assign to pollmann
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I think Pollmann recently checked in some fix for this.
Assignee: radha → pollmann
Status: REOPENED → NEW
Eric, sorry I didn't see your comemnt when I reopened it. marking it WFM again.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
mass-verifying WorksForMe bugs which haven't changed since 2001.12.31. set your search string in mail to "EmperorLondoMollari" to filter out these messages.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.