[3485] Chrome+Autofill is filling in fields it shouldn't

[HecKel]

Hi!

My personal configurations:
- OS: Windows XP
- Browser: Chrome 1.0.154.59

How to reproduce this bug:
- Open a random user profile
- Go to the Edit Account Settings
- Look at the email field > it is empty!

When I try to manual edit some user's configuration, in Chrome, after I  (try to) submit the form I've got a message saying that I have to introduce one email..., of course that happens, it is empty!

If I do that in Firefox, the email field has one email, so no problem at all!

[karlbenson]

I can't replicate this in Chrome (same version) not in rc1, nor the svn version.

Is your chrome set to save passwords/attempt to autofill information?

[HecKel]

yes, I have that that way...

[HecKel]

One more thing, I just realize that I have the password field filled, so, I think the email field should be filled as well, no?

[karlbenson]

These appear to be Chrome bugs when using autocomplete.
I'm not sure there is anything that SMF can do about it.

With autocomplete disabled both password and email fields work as they should (password field is empty, email field is completed)

[HecKel]

Thanks anyway.

[dbooksta]

I'm using the standard install of 1.1.9, PHP5, MySQL 5.

1. Problem: When a user goes to modify Account Related Settings the Email is blank and Change Password is populated with an unknown value.  If user does not re-enter his Email, Choose Password, Verify Password, and Current Password, no changes will be accepted!  Expected Behavior: Email should be populated by default with user's current Email address.  Choose Password should not be populated or required to Change Profile.  E.g., if a user only wants to change his Name he should only have to enter Current Password and click "Change profile" for the action to succeed -- without modifying any other user/profile values!

Worse,

2. Problem: When an admin goes to modify the Account Related Settings of another user's profile the default Email is the username of the admin!  Also, the Choose Password field is populated (I have no idea with what) and Verify Password is blank.  Expected Behavior: Email should by default contain the user's existing Email.  User's password should not be populated or required for admin to change the user's profile.

Regularexpression Edit: Given better title

[karlbenson]

are you using Google Chrome?
There seems to be an issue with Chrome and its auto-filling password/email fields.

[dbooksta]

Ah, yes -- looks like it's specific to Chrome; doesn't occur in IE.

[karlbenson]

The only solution I'm aware of at the moment is to disable auto-complete in Chrome.

I personally think this is a bug in Chrome, rather than SMF. And I'm not sure what we can do about it.

A google search discovered that Phpbb3 is having the same problem.
http://code.google.com/p/chromium/issues/detail?id=1854

[dbooksta]

I don't know what the standards (if any) are for auto-complete, but presumably Chrome is deciding to auto-complete that field because of the name property of the input:

<input type="text" name="emailAddress" size="30" value=... />

I assume that if we changed name to something different like "userEmailAddress" then Chrome wouldn't try to auto-complete it?

Same thing with the Choose password section of the Profile: Chrome must have seen name="passwrd1" in a different context on the site, so we would just need to use a different input name to prevent auto-complete here -- e.g., "newPasswrd1".

[karlbenson]

But what happens if you then alter the password of member #11.
When you goto the profile of member #17 it will then try to autofill the password you used for member #11.

I'm not sure whether we should do emailAddress_11 & passwrd1_11 (where 11 is the member id), and thus emailAddress_17.

I really don't think Google realises the effect that this autocomplete may have on alot of sites.

[dbooksta]

A quick search suggests that there is an autocomplete property we can use in input tags.  So we should just use:

<input autocomplete="off" ... />

for every Change password field as well as for the emailAddress on Modify Profile pages.

[karlbenson]

We can't use that because it is w3c invalid.
Its not part of the spec (which is why I didn't mention it)

https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML

[dbooksta]

I'm normally a stickler for standards, but AFAIK using the "autocomplete" property won't break w3c-compliant browsers, and in addition to solving the problem with a popular browser it is a good placeholder for any standard solution that might eventually be adopted, right?

[karlbenson]

It won't break them.

But the pages won't validate (we make sure all pages validate)

[karlbenson]

* merged two identical bug report topics together

[Orstio]

regularexpression, your solution would solve it, though it's not particularly clean. Don't other browsers who save passwords have a similar issue? E.g. if I were to save my details in FF?

(I don't save passwords in Chrome, or any other browser for that matter so it's not an issue for me)

Firefox does this same thing for certain fields.  It prioritizes autocomplete input over user input.

IE prioritizes user input over autocomplete input, making it less susceptible to this problem.

Regardless, if a person is concerned about their own security and privacy on the web, autocomplete is best turned off.  Makers of browsers that ship with autocomplete on by default need a good beating by soccer hooligans.

[dbooksta]

Agreed, but just to be clear this particular "bug" is a usability problem, not a security problem.

If we setup the profile pages to use different -- perhaps randomized -- Input names then we would have a W3C-valid solution to the usability problem.

[karlbenson]

After researching some google chrome bug reports it appears that they may have fixed the overwriting of fields which already had values.

Although we still need to stop them from pre-filling empty fields.
I do not think randomised fields is the solution.  It would likely break older 2.0 themes too.