Closed Bug 81851 Opened 19 years ago Closed 19 years ago

Password Manager never automatically logs me in.


(Core Graveyard :: Security: UI, defect, P1, major)

1.0 Branch


(Not tracked)



(Reporter: mozilla-bugs, Assigned: javi)




(Whiteboard: Somebody please check it in, r=javi, sr=blizzard, for checkin to the trunk)


(1 file)

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 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 
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 (
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 ==> 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 ==> 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


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
- 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

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
gets called (twice!) but fails because of the check for non-NULL prompt at

When I log in manually, the same function gets called and goes through without a

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

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
Keywords: mozilla0.9.2
Whiteboard: possible hitchhiker? → possible hitchhiker? want for mozilla 0.9.2, needs a=
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Blocks: 83989
a= 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, for checkin to the trunk
Fix checked into trunk
Closed: 19 years ago
Resolution: --- → FIXED
Blocks: 59652
Reporter, can you try this again with a build after 6/11 and report your 
I tried several builds since 06/11, inlcuding 2001061822, never had this problem
Product: PSM → Core
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.