180117 - Autofill of passwords causing problems on certain pages

Status: RESOLVED WORKSFORME

(SeaMonkey :: Passwords & Permissions, defect)

Description

[glenn hancock]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

We have a user login form for our company website that allows someone to login
and gain access to advanced features of the site.  This works perfectly. 
However, if I am an Admin for the site I also can add and modify new user
accounts to allow or disallow others to login.

When I pull up the user management page, it happens to have a password field as
well as a user name field on it for updating that information for users in the
event that something needs to be updated.

All browsers that I have used to date will do nothing with remembering a
password and user account until I click in the username field and begin to type
something.  This is not the case however with Mozilla as it sees the fields and
immediately pops up a login box which if selected causes the user account I am
updating to be updated with my login information.

This is something that I would like to see fixed or an option added to cause the
browser to act as all other browsers.  The problem I am reporting however is
that sometimes the system just logs me in and doesn't popup the login box which
causes the page to be displayed incorrectly right off the bat.  I have seen this
on numerous computers and enough to know it wasn't just a mistake as I and
others have seen it.

Thanks,

glenn

Reproducible: Sometimes

Steps to Reproduce:
1.Login to a site and have it remember you password and login
2.Pull up another page on that same site that allows you to modify another users
account.  This form must have a username and password fields on it in order to
kick off the login code.
3.See if it automatically updates the other users information with yours in
respect to username and password.

Actual Results:  
Most of the time it asks me to login again which is also a little wierd as the
username field already has a value in it and sometimes it just switches the
values without asking me to login.

Expected Results:  
I think that it shouldn't popup the login box until I actually begin to type
something in the login box.  Or at least give me an option in the browser
preferences to have it work this way...

Comment 1

[Andrew Hagen]

This behavior is by design. If you don't want Mozilla to remember your
username/password for a site, then tell it not to.

If you don't want your forms to be autofilled by Mozilla or other user agents,
then put the attribute    autocomplete=off  in the form tag in the HTML.

Seems like an invalid bug.

Comment 2

[Thomas Dodd]

Andrew, I'm not so sure this is invalid.

Shouldn't it be possible to force mozilla to ask always?

Glenn mentioned in email, that the HTML has a value for the field.
So mozilla is overwriting that value without asking. It should either ask, or
not change the value supplied by the page.
Why should he need a seperate profile to both use and administer the site?
Mozilla remembers the user info, which is great wen access as a user is being
done. If he logs in as administrator mozilla overwrites the field with the user
data stored, even though the page has prefilled the fields.

I think if the fields have a current value mozilla should either leave them
alone, or ask before changing the values.

Glenn. Can you add the autocomplete=off attribute to the admin pages if the
administrator is logged in? If that works, and doesn't cause problem with other
browsers, it is a work around. I still this the behavior should be changed, and
mozilla should not automatically override the supplied values.

Comment 3

[glenn hancock]

I am glad to hear someone agree with me.  yes, we are adding the entry
to the page which is actually all we need to do so I am happy with that
solution.

I also want to add that most of the time mozilla does ask for the login
information, it only every now and then that it doesn't seem to ask.  If
it always asked then it wouldn't be that big of a deal, but like you
said, I would like to see it not fill fields in if they are already
filled in.  that would in itself solve any future problems even with
forms that don't have the autofill set.

P.S.  we just got through testing the autocomplete function and it makes no
difference.  The login popup still comes up even though the fields are set to
autocomplete=off.  what exactly makes those popups display?  maybe we can change
the names of our fields on that form or something...

Thanks,

Thanks,

glenn

Comment 4

[Andrew Hagen]

On autocomplete=off, maybe you have to put it in the form tag?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie50/html/ACoff.asp

What does IE do in this situation? The same as Mozilla or different?

Could you post sample code?

Comment 5

[Thomas Dodd]

OK I tried this.
Using Andrew's suggestion, and grabing some code from the bugzilla login page :)

If, ALL password fields or the whole form is marked with autocomplete="off" it
won't store any information. If any type="password" field is not marked
autocomplet="off", mozilla asks about saving. After saving, other fields that
are autocomplete="off" ARE left alone.

The problem is, IF mozilla has stored info form before, it's used, even though
the autocomplete attribute is now set to "off". If you mark the fields or the
form autocomplete="off", and delete mozilla stored values, it's fine. But it
will use the stored values if they are there.

Since mozilla stores information site wide, useing the name attribute, changing
the variable names on the admin from will allow stored info on the main pages,
but protect the admin pages. Setting autocomplete="off" for the whole form will
prevent them from ever being stored for new users.

That way you don't have to disable passwords from the whole site, but will 
still be able to store other info. 

This is *still* a bug though. If I decide to not allow storing info, it should
override the previously saved data users have. This is about the sites control
over using stored info as well as storing it.

Also, I don't think site prefilled data sould be over written by stored data by
default. If the stored data includes non-password fields, and I have multiple
passwords stored (ie. for multiple user names), there's another, related bug.
Since I hve more than one stored password, mozilla asks which one to use. If
There is a field stored, that is still not marked autocomplete="off", mozilla
filles it in with the most recently selected value stored, even If I choose
"CANCEL" in the "Select User" dialog. If I cancel the selection, mozilla should
give me the page's default value, not a stored value.

Comment 6

[Daniel Veditz [:dveditz]]

> This is about the sites control over using stored info...

Well that's the problem isn't it? The browser is being written from the POV of
user control even in the face of site authors who try to frustrate them.

There are bugs, by the way, that complain that passwords should be
page-specific, not just site (and fieldname) specific. Would that solve this
problem?

Comment 7

[Andrew Hagen]

Yes, please respond tothe above comment. In addition, please post HTML code that
would serve as a testcase. 

Does IE have this problem?

Comment 8

[Thomas Dodd]

I think the per-page password might help. An option to use the site
default(first added?) if none define for a page would be great too.
Glenn said that IE handles this fine becaues it doesn't attempt to overwrite the
values set in HTML. I don't use IE so I cannot verify that.

As to who should be in control, I think mozilla is going the right way. Then
again I'm a user not a web developer. But I do think that 1) the defaults in the
HTML should be used unless I tell mozilla to use some other value, 2) mozilla
should ask me if I want to use the stored values, and 3) if I cancel the
username selection none of the stored values should be used, see comment #5.

I'll attach a simple file that has the problem. It must be accessed via http://
though, file:// doesn't store passwords. Change the names and passwd, click
login, save the password, fill in a different names and passd, login, and save
that one. Now moz ask which user name, click cancel, notice one of the names
changed?

If you add autocomplete="off" to the fields, mozilla still asks, and fills in
the data unless you remove it with the password manager. I tried lots of
combinations of autocomplete on the fields and the whole form, and saving the
data when asked. I also played with the filed names. Clearing the password data
for the site is also required to test the functions.

Comment 9

[Thomas Dodd]

Attachment: Simple form with passwords

Comment 10

[Andrew Hagen]

Typo in the posted HTML. If you fix the typo, does the problem still appear?

form action="autocomp.html" method="post"autocomplete="on"
                                        ^^

Comment 11

[Thomas Dodd]

Yes. The typo was from quickly going back to a previous version.
Try it an see.

Especially, change page so passwords ARE saved and filled. Then change some of
the fields (not the whole form) to no auto fill. See Comments #5 and #8.

Comment 12

[Mitchell Stoltz (not reading bugmail)]

->Password Manager. Steve, what's your take on this?

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Reassigning unconfirmed form and password manager bugs to the new owner

Comment 14

[Michiel van Leeuwen (email: mvl+moz@)]

Glenn, Is this the same problem as in bug 112260? If so, please mark this as a
duplicate.

Comment 15

[Andrew Schultz]

Glenn, Thomas: is this a dupe of bug 112260?

Comment 16

[eigentone]

*** Bug 308696 has been marked as a duplicate of this bug. ***

Comment 17

[eigentone]

Marking HTTP Auth account info as an "Internet Password" in the keychain, and html form account info as 
"Web Form Password" would solve this bug for me. This is how Safari does it and that implementaition 
works flawlessly for me in the majority of situations. 

Comment 18

[Misak Khachatryan]

This seems obsoleted. 

Comment 19

[Justin Wood (:Callek)]

Resolving Worksforme, from my skim of the above, and Misak's c#18.

Glenn, if this is still a problem in either the current stable suite (SeaMonkey 1.1.8 and soon to be .9) or the current "trunk" builds (SeaMonkey 2.0a1pre) please comment here and/or reopen the bug with further information.