523345 - Clearing Private Data Temporarily Removes Passwords [SeaMonkey 2, RC1/RC2/Final]

Status: RESOLVED DUPLICATE of bug 521263

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Dave Buco]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

I clear private data with 'saved passwords' not checked. Check the password manager and passwords are gone. After restarting the browser, all passwords are there. All works as expected. This happened in RC1 and continues to be an issue in RC.

Seems passwords are being "temporarily removed" upon clearing private data and then re-appears on restart.

Reproducible: Always

Steps to Reproduce:
1. Clear Private Data with 'saved passwords' un-checked
2. Open Password Manager

Actual Results:  
Passwords are gone.

Expected Results:  
Passwords should be there

Comment 1

[therube]

Confirmed.

In my case, I have Cache & Authenticated Sessions checked in Clear Private Data dialog.

Comment 2

[rsx11m]

Confirming per comment #1, despite not having tested it myself (both contributors here are regular MZ forum members with good standing).

Comment 3

[Dave Buco]

What's odd is that when the passwords seem to be "temporarily removed", the password mechanism as a whole seems to fail. Meaning that even though the passwords are, in fact, still there (somewhere), using the password manager is not possible until restart of the browser. Then all is well.

Example: If I clear private data (saved passwords unchecked) and check the password manager, the field is empty. I'll go to a Mozillazine Forums and log out. Then try to log in and there is no password, meaning I need to login manually. But the passwords are still there somewhere, as the reappear on restart.

Comment 4

[Jason Bassford]

Setting blocking question on 2.0 final also.  I'm not sure if it's feasible to block at this late date, but it can't hurt to pose the question.  Maybe if not blocking it could go into release notes / known issues or something...

Comment 5

[therube]

Broken:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091007 SeaMonkey/2.0pre

Works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091006 SeaMonkey/2.0pre

I may a bit wide in my search, but ...
Changes pushed after 2009-10-06 00:00:00, before 2009-10-08 00:00:00

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-10-06&enddate=2009-10-08

Comment 6

[Dave Buco]

Excellent narrowing it down, therube.

Comment 7

[rsx11m]

The only directly password-related bug I can find in your list is bug 381269, pushed Oct 06 16:37:42 PDT. It also refers to bug 521263 on breaking a test, which may be related to the observations here. A patch is posted there but not yet checked in, thus no use to test in a nightly build at the moment.

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #7)
> The only directly password-related bug I can find in your list is bug 381269,
> pushed Oct 06 16:37:42 PDT.

That is supposed to be triggered on startup only (case "final-ui-startup"). I haven't checked, though.

> It also refers to bug 521263 on breaking a test,
> which may be related to the observations here. A patch is posted there but not
> yet checked in, thus no use to test in a nightly build at the moment.

I was about to say "it's only about fixing a test" but the patch there contains changes to tasksOverlay.js's ExpirePassword() function. :-/

BTW: If the regression range from comment 5 is correct the below is for the Core part:

<http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-10-06&enddate=2009-10-08>

I don't see anything suspicious there, though.

Comment 9

[[e-mail]]

The code used to clear private data has a copy of the code used for the "Log Out" menuitem which itself was based on code written over 9 years ago. It turns out that this old "Log Out" code had a bug when dealing with a blank Master Password, but nobody would have really noticed since they hardly ever logged out and even if they did they weren't using their blank master password anyway, since their passwords were probably not encrypted.

The difference now is that the Master Password is always used to unlock the private encryption key when managing passwords, and logging out is also a default action of clearing private data, so hopefully the workaround in attachment 400689 [details] [diff] [review] will fix this bug too.

Comment 10

[Robert Kaiser]

I think we can go with relnoting this for 2.0 final, but we should really fix it for 2.0.1, IMHO.

Comment 11

[rsx11m]

(In reply to comment #9)
> attachment 400689 [details] [diff] [review] will fix this bug too.

You meant attachment 406889 [details] [diff] [review] in bug 521263, I assume.

Comment 12

[[e-mail]]

(In reply to comment #11)
> (In reply to comment #9)
> > attachment 400689 [details] [diff] [review] will fix this bug too.
> You meant attachment 406889 [details] [diff] [review] in bug 521263, I assume.
Yes; sorry for the typo.

Comment 13

[Robert Kaiser]

bug 521263 is marked fixed, is this bug here fixed now as well?

Comment 14

[Dave Buco]

(In reply to comment #13)
> bug 521263 is marked fixed, is this bug here fixed now as well?

Not having run nightlies since the release of 2.0, I'm not sure. I'll have to grab a nightly and try I suppose.

Comment 15

[Philip Chee]

Dave? Have you managed to test the latest nightly yet?

Comment 16

[Dave Buco]

(In reply to comment #15)
> Dave? Have you managed to test the latest nightly yet?

Excellent. The issue is fixed using: 
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091201 SeaMonkey/2.1a1pre

Comment 17

[Robert Kaiser]

So I'm inclined to say that this is ultimately a duplicate of what bug 521263 solved, then.