1064639 - Password Manager Fails to Fill-In Password When autocomplete=off

Status: RESOLVED INVALID

(Toolkit :: Password Manager, defect)

Description

[David E. Ross]

If a login process involves a user ID on one page and a password on a subsequent page, Password Manager fails to retrieve and fill-in the password from a set of saved passwords.  When I saw this happen, Password Manager requested my master password, which I supplied; but I got no password filled in.  

To complete the login, I went to Password Manager and selected the entry for the site.  After again inputting my master password, I was able to see and copy the password, which I then pasted into the password field.  

Note that this is a serious regression since many banking and financial Web sites now split logins to having the user ID on one page and the password on a subsequent page.

Comment 1

[David E. Ross]

Marking this as Severity = Major as there is a loss of a significant capability.  

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 SeaMonkey/2.29

This worked with SeaMonkey 2.26, to which I am reverting.

Comment 2

[Matthew N. [:MattN]]

Can you please provide the debug logging using the instructions from https://wiki.mozilla.org/Firefox:Password_Manager_Debugging. It will say why it's not filling in the password.

Comment 3

[David E. Ross]

Re comment #2:  

I cleared the Error Console before trying an afflicted Web page.  Whether in Safe Mode or not, there were NO Errors, very many Warnings, and 23 Messages (mostly about Login or Pwd).  The Messages alone are too many to copy one-at-a-time into a text file.  Is there a file or set of files for the Error Console that I can merely copy and attach to this bug report?

Comment 4

[Matthew N. [:MattN]]

A screenshot of the info lines in the console (at least starting with the most recent form/password ones) should help.

Comment 5

[David E. Ross]

Attachment: Messages -- Login Manager.jpg

As requested, screen shot of Login Manager entries in the Error Console.

Comment 6

[David E. Ross]

Attachment: Messages -- PwMgr.jpg

Screen shot of PwMgr entries in the Messages of the Error Console.  

Strange, but this time there were no Warning entries.  As before, there were no Error entries.

Comment 7

[Matthew N. [:MattN]]

Comment on attachment 8486189 [details]
Messages -- Login Manager.jpg

Based on line 2 in the screenshot, it seems like the site is using autocomplete=off now which would make this a dupe of bug 433238.

Comment 8

[David E. Ross]

(In reply to Matthew N. [:MattN] from comment #7)
> Comment on attachment 8486189 [details]
> Messages -- Login Manager.jpg
> 
> Based on line 2 in the screenshot, it seems like the site is using
> autocomplete=off now which would make this a dupe of bug 433238.

Bug #433238 has been open since 2008, but this was not a problem with SeaMonkey 2.26 only 3 days ago.  That is why I call this a regression.

Comment 9

[Matthew N. [:MattN]]

Are you sure the site didn't add @autocomplete=off at that time? Can you confirm that the password field or its form is using @autocomplete=off?

Comment 10

[David E. Ross]

The page for the password looks the same as it did last Friday, when Password Manager under SeaMonkey 2.26 did fill in the password.  I cannot tell if it changed since then, but I will know after I revert from SeaMonkey 2.29 to 2.26.  

For the user ID, I did see autocomplete=off.  However, I always manually enter the user ID.  For the password, I did not see any autocomplete=off.  This makes me think the problem is with supplying a password to a page that does not contain the associated user ID and not with autocomplete=off.  I will test that conjecture later.  

Here is the fragment of the Web page where the password is input: 

<!--PPE:Content-10-->Password<!--End PPE-->&nbsp;</span></b></td>
<td class="noTopBorder alignTop" valign="top"><span cmp="true" id="comp-LoginForm:PASSWORD" type="ValidatedPasswordInput" class="comp-ValidatedPasswordInput">
<span id="LoginForm:PASSWORD_propSpan" required="true"></span><span type="ERR_DESC" id="LoginForm:PASSWORD:err" text="You have entered an incorrect user name or password."></span>
<input pwfprops="," id="LoginForm:PASSWORD" name="LoginForm:PASSWORD" value="" maxlength="20" onblur="vg.validation.blur(this)" onchange="vg.validation.change(this)" onfocus="vg.validation.focus(this)" onkeydown="if(event.keyCode==13) {enterKeyPressed();}" size="24" style="font-size: 12px;" tabindex="1" class="txtInput" type="password"><span cid="comp-LoginForm:PASSWORD"></span></span></td>

Comment 11

[David E. Ross]

Today, I reverted back to SeaMonkey 2.26; but this problem persisted.  I then reinstalled the Remember Passwords 1.1 extension, and the problem was resolved.  I am reluctant to return to SeaMonkey 2.29 with the Remember Passwords extension because of the very explicit warning against using that extension with SeaMonkey 2.29.

Comment 12

[Matthew N. [:MattN]]

OK, so this sounds like an add-on issue. If that add-on always ignored autocomplete=off instead of only when saving (like Toolkit now does) then it should be updated to still ignore autocomplete=off when filling.

Comment 13

[David E. Ross]

There seems to be a misunderstanding.  I saw this problem with SeaMonkey 2.29 WITHOUT the Remember Passwords extension.  I saw this problem with SeaMonkey 2.29 running in Safe Mode.  This problem has nothing to do with any extension.  I merely cited the need for the Password Extension with SeaMonkey 2.26 because that might be a clue to where the problem lies.  

Existing passwords in the Password Manager database are not being filled in when the login involves inputting the user ID on one Web page and inputting the password on the next Web page.  This is a problem inherent in Toolkit's latest Password Manager and is not caused by any extension.  

Since resolving this in SeaMonkey 2.26 did require the Remember Passwords extension, I withdraw my comments that this is a regression.

Comment 14

[Matthew N. [:MattN]]

My understanding is that the behaviour you want (and saw in 2.26) was provided by the extension and what you are seeing is expected for @autcomplete=off.

We honour @autocomplete=off when filling in passwords. There is a separate existing bug about allowing the user to ignore that.

If you agree, please mark as INVALID again.

Comment 15

[David E. Ross]

What is the point of ignoring autocomplete=off for saving passwords if it is not ignored for using passwords.  

In any case, I could not find autocomplete=off for passwords in the affected Web pages; I could not find autocomplete at all.  Is "off" +the default when autocomplete is not specified?  The current draft specification for HTML5 indicates the default is "on".  How does Password Manager handle this?

Comment 16

[Matthew N. [:MattN]]

(In reply to David E. Ross from comment #15)
> What is the point of ignoring autocomplete=off for saving passwords if it is
> not ignored for using passwords.  

So you can still autocomplete the password from the username dropdown. i.e. we won't autofill the password but we will fill it manually.

> In any case, I could not find autocomplete=off for passwords in the affected
> Web pages; I could not find autocomplete at all.  Is "off" +the default when
> autocomplete is not specified?  The current draft specification for HTML5
> indicates the default is "on".  How does Password Manager handle this?

We check the input then check the form and default to on. You didn't show the <form> in your snippet. If there is no form then we won't fill at all.

Comment 17

[David E. Ross]

There is no user name dropdown because the user ID is input on the immediately previous Web page.  

In examining the complete password input Web page via [View > Page Source], I found that autocomplete=off is created via scripts, different scripts in the two different financial institution Web sites where I see this problem.  The problem here is thus caused by implementing bug #956906 without also implementing bug #1025703 and bug #348941 at the same time.  This might be considered a security vulnerability since the master password is requested even though the login password is not filled in, leaving the master password active.

Comment 18

[Matthew N. [:MattN]]

(In reply to David E. Ross from comment #17)
> There is no user name dropdown because the user ID is input on the
> immediately previous Web page.  

I know which is why I mentioned bug 433238.

> In examining the complete password input Web page via [View > Page Source],
> I found that autocomplete=off is created via scripts, different scripts in
> the two different financial institution Web sites where I see this problem. 
> The problem here is thus caused by implementing bug #956906 without also
> implementing bug #1025703 and bug #348941 at the same time.  This might be
> considered a security vulnerability since the master password is requested
> even though the login password is not filled in, leaving the master password
> active.

It was intentional that we didn't implement 956906 at that time. Bug 433238 is an alternative solution to your problem which we should do even for the multiple password case too.

Comment 19

[Matthew N. [:MattN]]

(In reply to Matthew N. [:MattN] from comment #18)
> It was intentional that we didn't implement 956906 at that time. Bug 433238
> is an alternative solution to your problem which we should do even for the
> multiple password case too.

Sorry, I meant bug 1025703 but to clarify I mean that we wanted to do something to respect autocomplete=off by not auto-filling but that doesn't stop us from providing UI like bug 433238 to allow manually filling.

Comment 20

[David E. Ross]

What has happened is that only part of the "autocomplete=off" password processing has been implemented.  Furthermore, that part makes it necessary to delete the Remember Passwords extension, which was the only workaround for the overall problem.  This leaves a situation that makes updating my browser unacceptable.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

Seems to me that this bug report is a combination of bug 433238, bug 348941, and some issue caused by a SeaMonkey addon that was broken by bug 956906. Unless we want to morph it to be about the SeaMonkey addon compat issue, I don't think it's tracking anything useful at this point.