Password Manager never automatically asks me for a password and never logs me in. When I go to a site that I have saved a password for, Mozilla would ask me for that site's password, not for the PM password. And when I ask it to save my password - still I am not promted to log into Password Manager. Not, however that if I go into Preferences -> Privacy and Cecurity -> Certificates -> Manage Security devices -> PSM Private Keys -> Login, and go ahead an log in, then Password Manager will start working (until I restart Mozilla, obviously). Also, I could not find anywhere the preferences for how often the PM should ask me for the password (e.g, once/after x minutes of inactivity/every time/etc). Preferences -> Privacy & Security -> Passwords does _not_ have it. I am currently using build id 2001051815 RH7 (installed from the RPMs from ftp.mozilla.org) on RedHat Linux 7.1 This used to work fine for me with Mozilla 0.9 RH6 RPMs on RedHat 6.2. However when I upgraded to RedHat 7.1 and installed Mozilla 0.9 RH& RPMs, it stopped working (I never tried going through the Preferences dialog with 0.9 though).
Reporter, can you create a new profile and try it again? I wonder if something got corrupted in a daily build along the way. Target -> 2.0
Target Milestone: --- → 2.0
I did try it at some point and it didn't help. But I only tried it briefly an I am not sure what version of Mozilla it was, so I should probably try it again. However, what I did try a lot of times is to remove *.db *.s *.w (but keep the prefs.js). If I do that, the next time I request a password to be saved, it promts me for a new PM password and after I set that, everything goes back to not working as it used to. BTW, I am not sure if it is related or it is a separate bug, but in the recent builds the checkbox that used to say "save this value using Password Manager" or something along those lines does not have any text next to it, but the checkbox is still there (and works if I do a manual Login).
Ah, and another thing - I use Mozilla on two machines and have the same problem on both of them. On second machine (also running RedHat 7.1) the profile was generated by migrating the Netscape-4 profile using Mozilla-0.9 (installed from RH7 RPMs) and there I had this problem from the beginning.
Workforme with the 5/22 WinNT Netscape 6 build. Make sure you "Encrypt Sensitive Information".
I do have "encrypt sencitive information". In any case, this bug prevents Mozilla from using saved information, no matter encrypted or not, but after I login manually, it is able to use it. BTW, I have a suspicion that this bug is restricted to RedHat 7.1 - it does not seem to occur with Mozilla 0.9 RH6 RPMs on RedHat 6.2, but it does occur with Mozilla 0.9 RPMs on RedHat 7.1 (although this may be an accidental coincidence).
> In any case, this bug prevents Mozilla from using saved information, no matter encrypted or > not, but after I login manually, it is able to use it. > I guess I should better explain what I've just said - what I meant is that even thought I have no way of checking whether the saved information is actully encrypted or not, I do know that Mozilla is unable to use that information until I manually log into the PSM Private Keys Software Security Device.
[Build ID 2001052510] If I do "Edit -> View Saved Data" before manually logging into the PSM "Software Security Device", I get an "Alert" window saying "Unable to unlock database" and I do not get prompted for the password. After I manually log in, I no longer get this message.
Verified that this bug still exists with build id 2001052819 on RedHat Linux 7.1 _with fresh profile_: 1) Created new profile "test" 2) Started mozilla -P test 3) Went to a site that requires authentication (http://members.spamcop.net/) 4) Entered auth info, selected for it to be saved by PSM. 5) Tasks -> Privacy & Security -> Password Manager -> Encrypt sensitive information. 6) Set master password appeared ==> chose password "test". 7) Exited Mozilla. 8) Started mozilla -P test 9) went to http://members.spamcop.net/ ==> was prompted for SpamCop passwd (saved info _not_ filled in), not Master passwd. 10) Pressed "Cancel" in the passwd dialog. 11) Edit -> Preferences -> Privacy and Security -> Certificates -> Manage Security Devices -> Software Security Device -> Login 12) Was prompted for master pass ==> entered master pass ("test"). 13) Went to http://members.spamcop.net/ ==> was prompted for SpamCop passwd, this time the saved info was properly filled in.
-> p1 Maybe related with the changed db passwd problem until the db has been unlocked.
Assignee: ddrinan → javi
Priority: -- → P1
I saw something like this on Linux, and it started to work once I went into my profile directory and deleted *.rdf and chrome/* (This would be conents in the /u/javi/.mozilla/javi/<random>.slt/ directory). Reporter could you try this work around? (Backup the relevant files if you want to keep them.)
Tried Alexsey's steps using Linux N6 build ID 2001053006. I was properly prompted to enter my security passwd when visiting a stored passwd site. Only differences were: different site (etrade), didn't start with -P but used the dialog with the set of profiles. So works for me. Reporter, can you try more recent build?
Note: Failure to change password before db has been unlocked bug is 83160. Not making it dependent on it, but reporter may want to check it.
Tried removing *.rdf and chrome/* per Javier's suggestion, didn't help (not too surprising since even creating new profile does not help). Stephane, what distro did you try this on? I believe (although I never double-checked it) that while it was working properly with Mozilla 0.9 6x RPMs on RedHat 6.2, when I upgraded the machine to RedHat 7.1 and installed Mozilla 0.9 7x RPMs, it stopped working (with exactly same profile).
To answer Stephane's question: I am still having this problem when using 2001053115 RH7 RPMs on RedHat 7.1
I noticed that the way RH7 RPMs are currently compiled is that configure in ran without --enable-crypto and then PSM is built separately by invoking BUILD_OFFICIAL=1 make BUILD_MODULES=psm2 Could this way of building Mozilla account for this bug (and bug #79318 as well)?
If I'm supposed to be using --enable-crypto it's news to me. I try and build the same way that the nighlies do. bryer+cls can you guys comment on what I should be using for the rpms?
Yes, --enable-crypto is the new officially sanctioned way to build psm/nss. The original stopgap measure of using BUILD_MODULES=psm2 method will still work (until someone breaks it). The nightly builds will be switched over to using --enable-crypto RSN.
Well, it was just a guess and it turned out to be a wrong guess. I've recompiled the RPM with --enable-crypto and it didn't seem to change anything. Still, I keep wondering if this bug is caused by the way the RPMs are build. After all, nobody with non-RPM builds could reproduce it.
I am seeing this on RH7.0 with plain old CVS builds.
Bug 79318 is definitely a packaging problem and I'm working on that now. I'm also going to use --enable-crypto now too. Who knows? It might fix the problem. :)
Bug 79318 is fixed now. Try pulling down the 0.9.1-pre2 rpm and see if it fixes this problem.
Unfortunatelly, still no luck.
OK, then I don't know what's causing it.
Tried the following on a RedHat 6.2 machine with 0.9 RH6 RPMs installed: - Copied a profile from a RH7.1 machine with May 31 build, where this problem exists. - Tried going to a password-protected site for which a password was saved (on a 7.1 machine). - Was _not_ prompted for the "Master password". - Quit mozilla, remove *.db from the profile directory, start Mozilla. - Go to the same site, save password in PSM, quit Mozilla. - Start Mozilla, go to the same site => now I _was_ prompted for the Master password. In other words, this bug probably means that RH 7.1 RPMs have problems _creating_ the right PSM profile. This also means that in order to see if the bug is fixed in a certain build, one has to create a new profile for each test (I haven't done it since May 30, will retest the latest "pre0.9.1" RPMs tomorrow) Also, tomorrow I will try to see what happens if I copy a "good" profile from a 6.2 machine to a 7.1 machine.
All my attempts at finding a workaround failed. Copying a "good" profile from a RedHat 6.2 system didn't help.
OK, I did some debugging and I think I am getting somewhere. It turned out that when I go to a password-protected site before logging in manually, the function PK11PasswordPrompt (http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSCallbacks.cpp#117) gets called (twice!) but fails because of the check for non-NULL prompt at http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSCallbacks.cpp#149 When I log in manually, the same function gets called and goes through without a problem. Anybody have an idea why this would happen?
I found the problem! nsSDRContext::GetInterface is returning uninitialized nsresult instead of NS_OK. It's just a 1-line trivial fix, can we get it into 0.9.1? Please? CC'ing thayes since he was the one who wrote that code.
Keywords: mozilla0.9.1, patch
Whiteboard: fix in hand
r=javi Oops, another in-initialized rv gets returned.
I do not have CVS access, so I'll need somebody's help with checking this in.
Whiteboard: fix in hand → fix in hand, need a=
The steps for reproducing this might be limited enough to not stop 091. Putting on the radar for other PDT opinions.
Whiteboard: fix in hand, need a= → possible hitchhiker?
Target Milestone: 2.0 → mozilla0.9.1
In is not too limited. On affected platforms PSM Wallet service is completely unavailable (unless users know the "manual login" workaround). It's not clear what platforms are affected, but at least RH 7.x seems to be affected.
0.9.1 is out the door already
Whiteboard: possible hitchhiker? → possible hitchhiker? want for mozilla 0.9.2, needs a=
Target Milestone: mozilla0.9.1 → mozilla0.9.2
a= email@example.com for checkin to the trunk. (on behalf of drivers)
Whiteboard: possible hitchhiker? want for mozilla 0.9.2, needs a= → Somebody please check it in, r=javi, sr=blizzard, firstname.lastname@example.org for checkin to the trunk
Fix checked into trunk
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Reporter, can you try this again with a build after 6/11 and report your findings?
I tried several builds since 06/11, inlcuding 2001061822, never had this problem again.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.