Last Comment Bug 523345 - Clearing Private Data Temporarily Removes Passwords [SeaMonkey 2, RC1/RC2/Final]
: Clearing Private Data Temporarily Removes Passwords [SeaMonkey 2, RC1/RC2/Final]
Status: RESOLVED DUPLICATE of bug 521263
: regression, relnote
Product: SeaMonkey
Classification: Client Software
Component: Passwords & Permissions (show other bugs)
: Trunk
: x86_64 All
: -- major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-20 06:28 PDT by Dave Buco
Modified: 2010-08-06 08:55 PDT (History)
8 users (show)
kairo: blocking‑seamonkey2.0-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Dave Buco 2009-10-20 06:28:30 PDT
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 2009-10-20 09:09:59 PDT
Confirmed.

In my case, I have Cache & Authenticated Sessions checked in Clear Private Data dialog.
Comment 2 rsx11m 2009-10-20 10:02:14 PDT
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 2009-10-20 12:24:45 PDT
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 2009-10-20 12:46:28 PDT
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 2009-10-20 16:49:02 PDT
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 2009-10-20 18:15:21 PDT
Excellent narrowing it down, therube.
Comment 7 rsx11m 2009-10-20 18:35:24 PDT
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) 2009-10-20 23:42:52 PDT
(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 neil@parkwaycc.co.uk 2009-10-21 01:36:01 PDT
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 (not working on stability any more) 2009-10-21 06:48:38 PDT
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 2009-10-21 06:52:31 PDT
(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 neil@parkwaycc.co.uk 2009-10-21 06:55:44 PDT
(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 (not working on stability any more) 2009-11-30 09:11:18 PST
bug 521263 is marked fixed, is this bug here fixed now as well?
Comment 14 Dave Buco 2009-11-30 21:58:58 PST
(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 2009-12-01 06:14:53 PST
Dave? Have you managed to test the latest nightly yet?
Comment 16 Dave Buco 2009-12-01 07:15:44 PST
(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 (not working on stability any more) 2009-12-01 07:52:09 PST
So I'm inclined to say that this is ultimately a duplicate of what bug 521263 solved, then.

*** This bug has been marked as a duplicate of bug 521263 ***

Note You need to log in before you can comment on or make changes to this bug.