Closed Bug 241110 Opened 21 years ago Closed 20 years ago

password manager won't show passwords

Categories

(SeaMonkey :: Passwords & Permissions, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: patrick.hendriks+bugzilla, Assigned: mvl)

References

Details

(Keywords: regression)

Attachments

(2 files)

with the new password manager it's possible to show the stored passwords. Or that's how the feature is supposed to work at least. I created a new profile, i logon to a site [let's say bugzilla] and do a TOOLS - PASSWORD MANAGER - MANAGE STORED PASSWORDS. In the new window i click SHOW PASSWORDS and i confirm this choice. A new column appears saying PASSWORDS, but this column is fully empty. Can't find this one in bugzilla yet. Screenshot coming up
Confirming with a Linux Gtk2 build from today. The password column is always empty for me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
wfm. Does the javascript console show any errors?
(In reply to comment #4) > wfm. > Does the javascript console show any errors? JS Console is clean
This one's probably for me. Hopefully, I'll find some time to look into it tomorrow. The good news is that I can reproduce the problem with today's nightly on Linux, although it definitely worked with some post-1.7b versions.
Status: NEW → ASSIGNED
This works for me with the latest 1.7 branch build on Linux, but is broken with trunk builds (again on Linux).
Keywords: regression
broken for me too on windows XP with build 2004041917
Just to add to Comment #8, it works fine for me on WinXP with Mozilla 1.7 RC1 (2004042109)
I'm going to download the latest build and check if there was a change, but I was talking about the trunk (1.8a) builds, not the 1.7 branch builds.
Requesting 1.7 blocker. http://www.mozilla.org/releases/mozilla1.7rc1/README.html#new says that this is one of the new features of 1.7 "Password Manager has a "show passwords" mode which will display saved passwords. You will need to enter your master password if you are using one." One nit, this is perhaps trunk only, so 1.7 branch should be safe? Can this be confirmed?
Flags: blocking1.7?
(In reply to comment #11) > Requesting 1.7 blocker. > One nit, this is perhaps trunk only, so 1.7 branch should be safe? > Can this be confirmed? Yes, see comment #7. Cancelling blocking request since this bug does not exist on the 1.7 branch.
Flags: blocking1.7?
(In reply to comment #12) > > One nit, this is perhaps trunk only, so 1.7 branch should be safe? > > Can this be confirmed? > > Yes, see comment #7. > > Cancelling blocking request since this bug does not exist on the 1.7 branch. Yeah, you confirmed it for Linux, but OS says "ALL" ;)
Broken on Windows and Mac also. OS All is correct.
Hardware: PC → All
Attached patch add idSplinter Review
Looks like some id got lost.
Assignee: dveditz → mvl
Comment on attachment 147561 [details] [diff] [review] add id btw, looks like a fallout from bug 221619
Attachment #147561 - Flags: superreview?(bryner)
Attachment #147561 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #147561 - Flags: review?(neil.parkwaycc.co.uk) → review+
Just to confirm, passwords column remains empty on the OS X build of Moz 1.8a as of the 20040506 build.
Ho-humm: The patch in attachment 147561 [details] [diff] [review] works just fine (Linux) - thanks :)
(In reply to comment #13) > (In reply to comment #12) > > > > Cancelling blocking request since this bug does not exist on the 1.7 branch. > > Yeah, you confirmed it for Linux, but OS says "ALL" ;) I can confirm that this bug does not exist on Mozilla 1.7_20040516 on Windows XP. It's pretty safe to say that this is not a 1.7 branch bug. Only the trunk.
The password display feature is OK but some clients see it as a security risk... But I guess that is what the Master password is for ..
requesting blocker. This is announced as one of the new features in 1.7. So it shouldn't be broken again in the next one. No workaround available.
Flags: blocking1.8a1?
Confirming bug in 1.8a1, Linux i686 gcc 2.95.3 compiled. Column stays empty.
(In reply to comment #21) > requesting blocker. This is announced as one of the new features in 1.7. So it > shouldn't be broken again in the next one. No workaround available. Mozilla 1.8a1 was already released.
Flags: blocking1.8a1?
(In reply to comment #23) > Mozilla 1.8a1 was already released. Darn, can't even turn my back for two days... ;) Anyway, bugzilla still showed that flag as the next one. But let's request 1.8a2 then.
Flags: blocking1.8a2?
*** Bug 244856 has been marked as a duplicate of this bug. ***
It's been almost a month, can we try a new SR?
Attachment #147561 - Flags: superreview?(bryner) → superreview?(darin)
column is empty in 1.8a1 for windows as well, just confirming.
(In reply to comment #0) > with the new password manager it's possible to show the stored passwords. Or > that's how the feature is supposed to work at least. > > I created a new profile, i logon to a site [let's say bugzilla] and do a TOOLS - > PASSWORD MANAGER - MANAGE STORED PASSWORDS. > > In the new window i click SHOW PASSWORDS and i confirm this choice. > A new column appears saying PASSWORDS, but this column is fully empty. > > Can't find this one in bugzilla yet. Screenshot coming up column is empty in 1.8a1 for windows as well, just confirming. Pierantonio from Italy
sigh. we know it is broken.
Whiteboard: We know
Attachment #147561 - Flags: superreview?(darin) → superreview+
Checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: We know
*** Bug 245686 has been marked as a duplicate of this bug. ***
(In reply to comment #31) > *** Bug 245686 has been marked as a duplicate of this bug. *** (In reply to comment #29) > sigh. we know it is broken. It Works now!!! Thanks!
fixed, no need for blocker request.
Flags: blocking1.8a2?
CC doc people
Verified FIXED with build 2004-07-25-09 on Windows XP.
Status: RESOLVED → VERIFIED
It works for the most part now (OS X trunk builds), but there are a limited number of web sites which do not display the password even though there does appear to be a password present as FF will log into the web site (which requires the password at log in). There must be something still going on to prevent these passwords from being displayed when most are.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: