Closed Bug 194650 Opened 21 years ago Closed 21 years ago

dynamic switching of user profiles does not logout password manager completely

Categories

(Core Graveyard :: Profile: BackEnd, defect)

x86
Windows 98
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.4beta

People

(Reporter: vdvo, Assigned: ccarlen)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210

If the Password Manager is "logged in", after switching away from and back to a
profile using dynamic switching (Tools->Switch Profile), the profile manager
doesn't work until the user manually logs out the password manager.

Reproducible: Always

Steps to Reproduce:
1. Have two profiles, and a password-protected (I have encryption turned on, but
that may not be needed) Password Manager in the active profile.
2. Make sure that you have "logged in" the Password Manager, i.e. you have
already entered the password during this session. (Use Tools->Password
Manager->Manage Stored Passwords - must come up)
3. Use Tools->Switch Profile to switch to another profile and then back to the
previously active profile.
4. Select Tools->Password Manager->Manage Stored Passwords - watch nothing
happen. Go to a site with saved login - watch nothing happen.
5. Select Tools->Password Manager->Logout.
6. Select Tools->Password Manager->Manage Stored Passwords - you're asked for a
password and the manager works fine again, including filling out login forms.
Actual Results:  
In step 4 of "Steps to Reproduce", password manager doesn't come up and login
forms aren't being filled. User isn't asked to login to the password manager.

Expected Results:  
As if the user had manually logged out of the password manager, the user should
have been asked for a password the first time they use the pwd. manager
(including visiting forms with saved login info) after a profile switch.

I suppose this is cross-platform, but leaving PC/Win98 until someone confirms.

Workaround: just use Tools->Password Manager->Logout.
Thanks for the detailed steps to repro. BTW, encryption does have to be on or
else you'll never be asked for a password in step 2.

The problem didn't show itself in the same way for me. Using your steps, it WFM.
But, if in step 3, when I switched to the new profile and tried to bring up the
password manager, it failed. Looking at the code, I see the problem. Patch
coming up.
Attached patch patchSplinter Review
Here's what was happening: The profile change observer was being set up be
either nsWalletlibService or nsSingleSignOnPrompt - whoever used signon data
first. Turns out, the wallet viewer code gets signon data thru neither of those
two components so it's possible to bring up the password manager without ever
causing the profile observer to be registered. Thus, when you switch profiles,
what's supposed to happen doesn't. The patch just moves the profile change
observer and the place it's registered to ensure that *whoever* touches this
data, the observer is registered. It also calls WLLT_ExpirePassword (which is
all Password Manager->Logout does) on a profile switch.

BTW, if a password had actually been used by wallet, things would have been
reset on a switch since wallet would have registered the profile change
observer.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4alpha
Thanks, Conrad.

Are you waiting with the review process for 1.3 release?
-> 1.4b
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Comment on attachment 115524 [details] [diff] [review]
patch

Dan, I heard you took over ownership of wallet. If not, suggest somebody?
Attachment #115524 - Flags: superreview?(dveditz)
Attachment #115524 - Flags: review?(kaie)
Comment on attachment 115524 [details] [diff] [review]
patch

sr=dveditz
Attachment #115524 - Flags: superreview?(dveditz) → superreview+
Comment on attachment 115524 [details] [diff] [review]
patch

r=kaie
Attachment #115524 - Flags: review?(kaie) → review+
It looks like the checkin for this bug this morning caused us to leak an
nsSecretDecoderRing.
It's fixed. The added code doesn't leak an nsSecretDecoderRing. The code has
always leaked it. It's just that the new code caused it to be created before it
would have been before. Filed bug 201592 on that.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
verified 2003042304
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: