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)
Core
DOM: Navigation
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?
Comment 1•23 years ago
|
||
> 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
Reporter | ||
Comment 2•23 years ago
|
||
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?
Comment 3•23 years ago
|
||
Are you guys both testing the same page? :)
Comment 4•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
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
Reporter | ||
Comment 6•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 7•23 years ago
|
||
I also can not reproduce this. Marking WORKSFORME, but please reopen if you can
find a way to reproduce it!
Comment 8•23 years ago
|
||
Reopening to assign to pollmann
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 9•23 years ago
|
||
I think Pollmann recently checked in some fix for this.
Assignee: radha → pollmann
Status: REOPENED → NEW
Comment 10•23 years ago
|
||
Eric, sorry I didn't see your comemnt when I reopened it. marking it WFM again.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 11•22 years ago
|
||
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.
Description
•