Closed Bug 635783 Opened 15 years ago Closed 14 years ago

Password Manager does not show stored passwords

Categories

(SeaMonkey :: Passwords & Permissions, defect)

Product:
SeaMonkey
Component:
Passwords & Permissions
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 665826

People

(Reporter: christian.lindemann, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20110209 Firefox/4.0b11 SeaMonkey/2.1b2 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20110209 Firefox/4.0b11 SeaMonkey/2.1b2 The fill-out of web page form fields with stored passwords works good, and also the replacement of passwords do. But I cannot see any password in the tab which belongs to that new Data Manager (SM 2.1b2, German version). Reproducible: Always
Good morning Mr. Lindermann, As per passwords on the data manager. Please select a site that you have saved passwords for. Then select the passwords tab. Next select the Show Passwords button near the bottom right corner. If this does not solve your issue please report back. If this does solve your issue please tell us that too. For me, all I can say is WORKSFORME
I tried the way you described (once again) but it's still impossible to work with that saved passwords. In earlier versions it was also possible to let SM show the passwords in plain text, but both features unfortunately does not work in this beta. BTW, the label on the password tab is always light grey (not black), and if I choose "only passwords" ("Nur Passwörter") from the dropdown box there isn't listed any domain in the domain listbox below the dropdown box. Even though I use dozens of passwords in the meantime. ;o) I got this version from http://www.seamonkey.at/download/2.1b2
I have rechecked with sm2.1b2 and latest nightly and this still seems to work perfectly for me. Do you have any addons that mess with password management. Also even if you don't you may want to try on a clean profile. Also check the older password manager see if that functions properly for you.
Sorry, the toolkit password manager UI is located at: chrome://passwordmgr/content/passwordManager.xul Just enter that in your address bar and see if that works for you.
Hey, that works fine. Thanks a lot. So I will put the link into the bookmarks for now. ;o)
Note to the higher ups: This was a non-issue for my self I would consider this an isolated case. I would say leave it as it is in case someone else has this issue. NOTE to anyone having this issue: The workaround using the toolkit's password manager is not recommended as Seamonkey does not control the toolkit and this URL may change. So for a work around to an issue I cannot confirm this cannot considered reliable one.
Christian, Can you retest with the en-US version. Sometimes strange bugs are due to incomplete localizations.
Hi Philip, I tried the English/US version as you suggested, and everything worked fine. I took it from from http://www.seamonkey-project.org/releases/2.1b2 now. Shortly after I tested the password function in that version I uninstalled it an installed the German version from the same source (http://www.seamonkey-project.org/releases/2.1b2). What should I say, I can use the password manager in this (German) version, too. Philip, you found the mistake. Congratulations to you! Last, but not least, thanks to all of you developers for making such a great program suite. BTW, the bug which I reported concerning the mail notification (https://bugzilla.mozilla.org/show_bug.cgi?id=634732) also doesn't occur in the German release downloaded from the website above (..project.org..). I hope I didn't cause too much trouble. :o)
Good morning, I've some bad news: the problem is still there! What did I do? When I installed the US version for testing I took my notebook. SM has never been installed before on this machine, so there couldn't exist any old profile (or password) data. I visited a website and used the password saving function. I closes SM, started SM again and tested the password manager / data manager -> password has been saved correctly and it was also possible to see it in plain text. Then I carried out a profile backup on my desktop pc (where the described problem occured first), uninstalled SM, deleted the whole SM folder in the personal documents an preferences folder of WinXP, installed SM again and tested the password function on this machine, too. In this way I can save and see passwords as well. And now when I try to implement the old passwords by copying the files key3.db and signons.sqlite as described (http://kb.mozillazine.org/Transferring_data_to_a_new_profile_-_SeaMonkey) the problem is there again. I guess I made a little mistake at the beginning of migration from the earlier SM version to SM2.1b2: When I started SM2 on the old profile I didn't know something about this migration problems, an so I 'migrated' the old profile in the same way as I did in earlier versions or re-installations - I just copied the whole backupped profile data into the SM profile folder. The password problem wasn't really visible for me in that moment. By the way, I just found a file called signons3.txt in the profile folder, and it seems to contain _all_ of my used passwords in this form: --- . http://www.domain.tld loginname fdgbfrdhtjhterhernbfgbftgtji6unhnjzizertbvunti7bevh= *pw dbfghtntjzjzmjz,lkzmkuzuiiuinziubiiitburuerezrubne== --- But how make this password list visible in the new SM2 data manager? That's still the question. :o)
Maybe it depends on a file called permissions.sqlite? I uninstalled SM an the profile data and installed SM once again. After automatically creating the profile folder I took some files step by step from the old profile. I renamed the new files abc.sqlite as abc.sqlite.bak and copied the file abc.sqlite from the old profile into the new profile folder. Then I started SM (for each changed file). When I took the permissions.sqlite from the old profile into the new one the password problem occured. So I'll take the new permissions.sqlite for now. Unfortunately I now have the bug again which I described here: https://bugzilla.mozilla.org/show_bug.cgi?id=634732
signons3.txt is probably from SeaMonkey 1.x. If in 2.0 or 2.1b2 you have signons.sqlite and you don't have any passwords in it worth keeping, delete or rename it while SM2.1b2 is shut down and then restart. The passwords in signons3.txt should then be imported.
I think I have the same problem. After migration from Seamonkey 2.0.13 to 2.1 final the list of domains in datamanager is empty, if I select "passwords only". The passwords are still usable (e.g.: I'm currently loggedin in bugzilla via my stored user and password). The passwords are also visible, if I open the old password manager as described above. This is an old SeaMonkey installation and profile as well (aka SeaMonkey 1.x and earlier). I tried the suggestion in comment #11 without success. Googling around, I found some threads where similar problems are mentioned. http://forums.mozillazine.org/viewtopic.php?f=6&t=2227841 http://web.archiveorange.com/archive/v/ffCsSZB1LN3He3klAyge They all suggest a problem with migrated profiles.
If you select another category, say Cookies, do both the Domain & the cookie data fields populate? If not, then this might apply, Bug 665826 - Data Manager about:data is not IPv6 ready?
Oh, & anything relevant in Error Console?
The problem seems indeed be related to Bug 665826, because I get the same exception in the Error Console, when I open the Data Manager. Domains, however, are displayed fine, when I select All Data Types, Cookies Only or Permissions Only. When I click on a domain I can change the cookie permissions as expected. I also get the exception, when I click on a domain and the permissions tab is active. If I click on the same domain and the cookies tab is active I get no exception. Exception is thrown, when I then click on the Permissions tab. This is the same for all domains with cookie permissions. --- Error Console --- Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIURLParser.parseURL]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: chrome://communicator/content/dataman/dataman.js :: domain_getDomainFromHost :: line 460" data: no] Because the exception indicates an URI parsing error, I checked the sites in the old password manager. Some look indeed unusual: - http://localhost - http://dev.eclipse.org (Eclipse Archives) - http://www.cincomsmalltalk.com (CSTCP) - mailbox://mx.freenet.de (mailbox://mx.freenet.de) - www.somesite.com Notice the information in brackets. I don't know if this can cause parsing errors... Some sites did not have any protocol information (no http:// identifier). I have found some unusual domains in the context of the cookie permissions: - * - ipv4 addresses - localhost
(In reply to comment #15) > --- Error Console --- > Error: uncaught exception: [Exception... "Component returned failure code: > 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIURLParser.parseURL]" nsresult: > "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: > chrome://communicator/content/dataman/dataman.js :: domain_getDomainFromHost > :: line 460" data: no] Thanks, I guess we need to become more forgiving in parsing there, to allow strange old data and such stuff. > Some look indeed unusual: > - http://localhost > - http://dev.eclipse.org (Eclipse Archives) > - http://www.cincomsmalltalk.com (CSTCP) > - mailbox://mx.freenet.de (mailbox://mx.freenet.de) Those look all normal to me (realms in brackets are normal). > - www.somesite.com That one, without a URL scheme, could maybe be a problem. I'm not convinced the problem is passwords though, as the actual problem might actually happen before passwords even get read. Could you go to about:config, create a new BOOL preference there called "data_manager.debug" and set it to true? After launching the Data Manager again, what are the last messages you see in the Error console before that error you posted above?
data_manager.debug=true produces the following output to the Error Console, when opening the Data Manager: ... cached: adserver.betandwin.de -> betandwin.de added domain: betandwin.de (with flag hasPermissions) cached: www.sponsorads.de -> sponsorads.de cached: www.kde.org -> kde.org cached: sso-de.bestofmedia.com -> bestofmedia.com Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIURLParser.parseURL]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: chrome://communicator/content/dataman/dataman.js :: domain_getDomainFromHost :: line 460" data: no] The domain bestofmedia.com is available in the Data Manager. According to Data Manager and the old cookie manager the following cookie permissions are set: ads.bestofmedia.com -> Block sso-de.bestofmedia.com -> Allow for session No cookies are stored.
Oh... I just noticed that the last url in my trace (sso-de.bestofmedia.com) and the url in Bug 665826 (http://test-ipv6.comcast.net) have one thing in common. Both urls contain a dash (-). coincidence?
I have same problem. After upgrading from 2.0.14 to 2.1/2.2 I can't see any passwords in DM. And most permissions too. Even on sites that I can logged in have gray tabs in DM. I think trouble lay in old permissions.sqlite file. I tried to import old data by SqliteManager on clean installation. Same result. Illegal symbols? Sorry for my English :-(
(In reply to comment #17) > The domain bestofmedia.com is available in the Data Manager. Yes, the problem happens with the next thing it does after completing the bestofmedia.com permission. So 1) it's probably a permission that causes the problem, and 2) it's the one delivered back right after the sso-de.bestofmedia.com entry. Next step will need to be to find out which one that is.
There is no bestofmedia.com permissions in my profile. I don't know this site. There should be other reason.
I'm experiencing the same issue with 2.2 on a win7 x64 machine. This was after upgrading from 2.0.14. I had started <a href="http://forums.mozillazine.org/viewtopic.php?f=40&t=2255549">thread</a> before someone directed me here.
Thanks for the help here, I'm duping this against bug 665826 because the patch there will fix the problem here as well, no matter if it's IPv6 at fault or not.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
I can see cookie after upgrading 2.0.14 --> 2.1 / 2.2 But I cannot see Passwords and most of Preference.
(In reply to comment #24) > I can see cookie after upgrading 2.0.14 --> 2.1 / 2.2 > But I cannot see Passwords and most of Preference. Yes, we know the bug exists. And the patch in bug 665826 will fix it.
Ok, I just upgraded to Seamonkey 2.3 and all my stored passwords are available in the data manager. There are still some error messages in the error console though: e.G.: Error: Error while trying to get domain from host name: localhost Source File: chrome://communicator/content/dataman/dataman.js Line: 135 Error: [Exception... "Component returned failure code: 0x804b0050 (NS_ERROR_INSUFFICIENT_DOMAIN_LEVELS) [nsIEffectiveTLDService.getBaseDomainFromHost]" nsresult: "0x804b0050 (NS_ERROR_INSUFFICIENT_DOMAIN_LEVELS)" location: "JS frame :: chrome://communicator/content/dataman/dataman.js :: domain_getDomainFromHost :: line 485" data: no] Source File: chrome://communicator/content/dataman/dataman.js Line: 135 ... Error: Error while trying to get domain from host name: 192.168.80.1 Source File: chrome://communicator/content/dataman/dataman.js Line: 135 Error: [Exception... "Component returned failure code: 0x804b0051 (NS_ERROR_HOST_IS_IP_ADDRESS) [nsIEffectiveTLDService.getBaseDomainFromHost]" nsresult: "0x804b0051 (NS_ERROR_HOST_IS_IP_ADDRESS)" location: "JS frame :: chrome://communicator/content/dataman/dataman.js :: domain_getDomainFromHost :: line 485" data: no] Source File: chrome://communicator/content/dataman/dataman.js Line: 135 ... Error: Error while trying to get domain from host name: nexus Source File: chrome://communicator/content/dataman/dataman.js Line: 135 Error: [Exception... "Component returned failure code: 0x804b0050 (NS_ERROR_INSUFFICIENT_DOMAIN_LEVELS) [nsIEffectiveTLDService.getBaseDomainFromHost]" nsresult: "0x804b0050 (NS_ERROR_INSUFFICIENT_DOMAIN_LEVELS)" location: "JS frame :: chrome://communicator/content/dataman/dataman.js :: domain_getDomainFromHost :: line 485" data: no] Source File: chrome://communicator/content/dataman/dataman.js Line: 135 ... 192.168.80.1 is the IP-Address of my router nexus -> name of my computer The settings for the above domains are, however, being correctly displayed. So apart from the error messages in the console, this bug is indeed fixed in Seamonkey 2.3. Thank you very much.
(In reply to snfuchs from comment #26) > Ok, I just upgraded to Seamonkey 2.3 and all my stored passwords are > available in the data manager. Very good. > There are still some error messages in the error console though: Those should all be only visible with data_manager.debug=true and go away when setting it to false or removing it, right? > The settings for the above domains are, however, being correctly displayed. Then it's OK. I added those messages in debug mode just so we can more easily find any further issues if they come up. Right now, those just tell us that for all those three, we cannot derive a "toplevel domain", for "localhost" and "nexus" because they don't have multiple domain levels, i.e. no .tld ending, and for "192.168.80.1" unsurprisingly because it is an IP address. That's alright for all three cases and no real errors.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #27) > > > There are still some error messages in the error console though: > > Those should all be only visible with data_manager.debug=true and go away > when setting it to false or removing it, right? > You are right, after removing the data_manager.debug setting I don't get any messages in the Error console. So everything works fine. Bug is fixed.
You need to log in before you can comment on or make changes to this bug.