The default bug view has changed. See this FAQ.

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

RESOLVED DUPLICATE of bug 521263

Status

SeaMonkey
Passwords & Permissions
--
major
RESOLVED DUPLICATE of bug 521263
8 years ago
7 years ago

People

(Reporter: Dave Buco, Unassigned)

Tracking

({regression, relnote})

Trunk
x86_64
All
regression, relnote
Bug Flags:
blocking-seamonkey2.0 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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
(Reporter)

Updated

8 years ago
Summary: Clearing Private Data Temporarily Removes Passwords → Clearing Private Data Temporarily Removes Passwords [SeaMonkey RC1/RC2]
(Reporter)

Updated

8 years ago
Summary: Clearing Private Data Temporarily Removes Passwords [SeaMonkey RC1/RC2] → Clearing Private Data Temporarily Removes Passwords [SeaMonkey 2, RC1/RC2]

Comment 1

8 years ago
Confirmed.

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

Comment 2

8 years ago
Confirming per comment #1, despite not having tested it myself (both contributors here are regular MZ forum members with good standing).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-seamonkey2.0.1?
(Reporter)

Comment 3

8 years ago
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

8 years ago
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...
Flags: blocking-seamonkey2.0?

Comment 5

8 years ago
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

Updated

8 years ago
Keywords: regression
Version: unspecified → Trunk
(Reporter)

Comment 6

8 years ago
Excellent narrowing it down, therube.

Comment 7

8 years ago
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.
(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

8 years ago
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

8 years ago
I think we can go with relnoting this for 2.0 final, but we should really fix it for 2.0.1, IMHO.
Flags: blocking-seamonkey2.0?
Flags: blocking-seamonkey2.0.1?
Flags: blocking-seamonkey2.0.1+
Flags: blocking-seamonkey2.0-
Keywords: relnote

Comment 11

8 years ago
(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.
Depends on: 521263
(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.
OS: Windows NT → Windows Server 2008
(Reporter)

Updated

8 years ago
OS: Windows Server 2008 → All
Summary: Clearing Private Data Temporarily Removes Passwords [SeaMonkey 2, RC1/RC2] → Clearing Private Data Temporarily Removes Passwords [SeaMonkey 2, RC1/RC2/Final]

Comment 13

7 years ago
bug 521263 is marked fixed, is this bug here fixed now as well?
(Reporter)

Comment 14

7 years ago
(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

7 years ago
Dave? Have you managed to test the latest nightly yet?
(Reporter)

Comment 16

7 years ago
(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

7 years ago
So I'm inclined to say that this is ultimately a duplicate of what bug 521263 solved, then.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 521263

Updated

7 years ago
Flags: blocking-seamonkey2.0.1+
No longer depends on: 521263
You need to log in before you can comment on or make changes to this bug.