Closed Bug 44291 Opened 24 years ago Closed 24 years ago

Getting new-password dialog instead of change-password dialog

Categories

(Core Graveyard :: Security: UI, defect, P3)

1.0 Branch
x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: morse, Assigned: thayes0993)

References

Details

(Whiteboard: [nsbeta2-])

Under the following scenario I get the new-password dialog (does not ask for old 
password) even though I asked for a change of password.

1. Create a new profile and bring up the browser
2. Go to http://people.netscape.com/morse/password.htm
3. Fill in any arbitrary username and password, then submit form
4. Answer "yes" to the "do you want to save" dialog
5. Dismiss the encryption-disclaimer dialog
6. Dismiss the security-alert dialog
7. From the menu select tasks->privacy->password-manager->encrypt
8. PSM dialog for creating master password appears.  Enter password and press OK
9. Security alert appears (this is bug 44044).  Click OK
10. Security alert appears again (more bug 44044).  Click OK again.
11. From the menu select tasks->privacy->password-manager->change-password

The dialog that appears now has text fields for "new password" and "new pasword 
(again)".  It does not have a text field for "old password" which is supposed to 
be on the change-password dialog.  So this is the new-password dialog instead of 
the old-password dialog.  Furthermore, if I enter a new password, it apparently 
does nothing -- the password does not get changed.

I believe that if I exit and then reenter the browser, and then try to change 
the password, that I will get the correct change-password dialog.
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
Status: NEW → ASSIGNED
Per beta2 triage, moving from [nsbeta2+] to [nsbeta2-], putting on nsbeta3 
nominee radar.
Keywords: nsbeta3
Whiteboard: [nsbeta2+] → [nsbeta2-]
This appears to be caused by the client caching the content of PSM dialogs.
Changing PSM to set Pragma: no-cache on the HTTP results fixes this bug.

Checkin is pending for this.
Worksforme. This appears to be fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Well, since I didn't check in the change, I don't know why this problem would 
have disappeared.  Is anyone aware of changes in the Mozilla caching methods 
that would have corrected this problem?
Blocks: 48444
Verified worksforme.
Status: RESOLVED → VERIFIED
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.1
Mass changing Security:Crypto to PSM
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.