Password Manager never automatically logs me in.

VERIFIED FIXED in mozilla0.9.2


Core Graveyard
Security: UI
17 years ago
a year ago


(Reporter: Aleksey Nogin, Assigned: Javier Delgadillo)


1.0 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


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


(1 attachment)



17 years ago
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).

Comment 1

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

Comment 2

17 years ago
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).

Comment 3

17 years ago
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.

Comment 4

17 years ago
Workforme with the 5/22 WinNT Netscape 6 build. Make sure you "Encrypt Sensitive 

Comment 5

17 years ago
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).

Comment 6

17 years ago
> 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.

Comment 7

17 years ago
[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.

Comment 8

17 years ago
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.

Comment 9

17 years ago
-> p1 
Maybe related with the changed db passwd problem until the db has been unlocked.
Assignee: ddrinan → javi
Priority: -- → P1

Comment 10

17 years ago
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.)

Comment 11

17 years ago
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?

Comment 12

17 years ago
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.

Comment 13

17 years ago
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).

Comment 14

17 years ago
To answer Stephane's question: I am still having this problem when using
2001053115 RH7 RPMs on RedHat 7.1

Comment 15

17 years ago
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?

Comment 17

17 years ago
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.

Comment 18

17 years ago
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. 

Comment 19

17 years ago
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.

Comment 22

17 years ago
Unfortunatelly, still no luck.
OK, then I don't know what's causing it.

Comment 24

17 years ago
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.

Comment 25

17 years ago
All my attempts at finding a workaround failed. Copying a "good" profile from a
RedHat 6.2 system didn't help.

Comment 26

17 years ago
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?

Comment 27

17 years ago
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.

Comment 28

17 years ago
Created attachment 37506 [details] [diff] [review]
Return NS_OK properly.


17 years ago
Keywords: mozilla0.9.1, patch
Whiteboard: fix in hand

Comment 29

17 years ago

Oops, another in-initialized rv gets returned.

Comment 31

17 years ago
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=

Comment 32

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

Comment 33

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


17 years ago
Blocks: 83989

Comment 35

17 years ago
a= for checkin to the trunk.
(on behalf of drivers)


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

Comment 36

17 years ago
Fix checked into trunk
Last Resolved: 17 years ago
Resolution: --- → FIXED


17 years ago
Blocks: 59652

Comment 37

17 years ago
Reporter, can you try this again with a build after 6/11 and report your 

Comment 38

17 years ago
I tried several builds since 06/11, inlcuding 2001061822, never had this problem


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


10 years ago
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.