dynamic switching of user profiles does not logout password manager completely

VERIFIED FIXED in mozilla1.4beta


Core Graveyard
Profile: BackEnd
15 years ago
2 years ago


(Reporter: Vaclav Dvorak, Assigned: Conrad Carlen (not reading bugmail))


Windows 98

Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
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.

Comment 1

15 years ago
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.

Comment 2

15 years ago
Created attachment 115524 [details] [diff] [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


15 years ago
Target Milestone: --- → mozilla1.4alpha

Comment 3

15 years ago
Thanks, Conrad.

Are you waiting with the review process for 1.3 release?

Comment 4

15 years ago
-> 1.4b
Target Milestone: mozilla1.4alpha → mozilla1.4beta

Comment 5

15 years ago
Comment on attachment 115524 [details] [diff] [review]

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]

Attachment #115524 - Flags: superreview?(dveditz) → superreview+

Comment 7

15 years ago
Comment on attachment 115524 [details] [diff] [review]

Attachment #115524 - Flags: review?(kaie) → review+
It looks like the checkin for this bug this morning caused us to leak an

Comment 9

15 years ago
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.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 10

15 years ago
verified 2003042304
Blocks: 201592
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.