194650 - dynamic switching of user profiles does not logout password manager completely

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Vaclav Dvorak]

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

[Conrad Carlen (not reading bugmail)]

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

[Conrad Carlen (not reading bugmail)]

Attachment: patch

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.

Comment 3

[Vaclav Dvorak]

Thanks, Conrad.

Are you waiting with the review process for 1.3 release?

Comment 4

[Conrad Carlen (not reading bugmail)]

-> 1.4b

Comment 5

[Conrad Carlen (not reading bugmail)]

Comment on attachment 115524 [details] [diff] [review]
patch

Dan, I heard you took over ownership of wallet. If not, suggest somebody?

Comment 6

[Daniel Veditz [:dveditz]]

Comment on attachment 115524 [details] [diff] [review]
patch

sr=dveditz

Comment 7

[Kai Engert [:KaiE:]]

Comment on attachment 115524 [details] [diff] [review]
patch

r=kaie

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It looks like the checkin for this bug this morning caused us to leak an
nsSecretDecoderRing.

Comment 9

[Conrad Carlen (not reading bugmail)]

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.

Comment 10

[Grace Bush]

verified 2003042304