2

Our site has a profile update page which allows the user to change their password and other basic information. This page has been in production since 2006. Recent changes to Chrome have broken the way the page works, and I don't see any easy fix for this.

Here is the situation: when the user goes to this page, there are among other things fields for an email address and confirmation email address, and a password and confirmation password. If the user wants to change either the email or address or password, she enters new values into the desired fields. If they don't want to change them, they leave them blank. That is how it is supposed to work.

However, due to "autocomplete", the browser may try to populate these fields. This is very bad in this case, leading to confusing the user. The main reason is because it appears that the user is trying to change their email to one that is already in use, and they get an error message about the email already being in use. This is very confusing, because they did not even enter the email address; the browser did. In addition, of the four fields, Chrome only populates two of them. Thus the user is told the fields don't match and they start struggling with that. I can see a lot of user frustration in this picture.

Up until very recently, there has been a simple solution: use autocomplete="off" on the four fields (the two email addresses and two passwords). And it has worked fine since around 2006. And still works fine in the other major browsers.

At some point I moved the autocomplete off into javascript, due to compliance issues. Then when that started failing, I moved it into jquery, to make sure the DOM was loaded. At first the jquery solution seemed to work, for a while.

But now Chrome insists on autofilling those fields no matter what. I have tried changing the id of the field, but for some reason Chrome sees through this as well.

I have seen discussions elsewhere about Chrome ignoring autocomplete="off". And usually the discussions tend to be "anti-autocomplete-off" as though it is a bad thing because it causes unpredictable browser behavior. I do not dispute this viewpoint.

But is becoming a real problem in our current design for Chrome users, and I don't see such a simple solution anymore such as using autocomplete="off". I am afraid I am going to have to make a significant change to deal with this problem. I might for example have to hide the fields and only have them appear upon clicking a checkbox, or something like that. (But I am guessing Chrome is going to defeat that as well.)

Apparently the simplicity of autocomplete off, or obfuscating the id of the field is not going to work. So my next approach would be to create my own password entry field using a text field, and using javascript trickery to obfuscate the entry with asterisks, to provide the functionality of the password-type field. Seems like a colossal waste of effort. And for Chrome only.

Worse of all, Chrome is not even populating the fields properly as you can see from the screenshot.

Can anyone suggest a relatively simple approach?

Chrome populating fields that should be left blank

Improve this question
5
  • There's a growing school of thought that obfuscating password fields is a waste of the anyway, since it only provides over-the-shoulder security. One compromise is to use JS to change a text field to password on blur.
    – Blazemonger
    Commented Apr 16, 2013 at 11:45
  • I have added a workaround similar to that suggested by Blazemonger, plus some additional hacks. After DOM is loaded, change the field type to "text". If javascript not enabled, this leaves it at "password", which is secure. Having the field "text" at this point prevents the autofill in Chrome. Then, onfocus, change the field back to "password". That way we get all the functionality, but avoid the autofill. For Firefox, which behaves differently, when the DOM is loaded, just set the value of the field to blank. Works in the 5 main browsers we support.
    – Jeffrey Simon
    Commented Apr 28, 2013 at 0:50
  • Why can't you just use the autocomplete attribute? Can't imagine what you need to be complying with.
    – DisgruntledGoat
    Commented Jun 10, 2013 at 9:44
  • @DisguntledGoat - as I said in the original post, the problem is caused because this is not a field where the user should enter anything. It is only used for changing the email, and should be left blank otherwise. The autocomplete works, but fills in the field, making the system think they want to change their email to the same as at present, plus causes validation errors because the second field is not autocompleted. All this is explained in the original question.
    – Jeffrey Simon
    Commented Jun 15, 2013 at 20:26
  • UPDATE to my comment of 28-Apr-13 in which I said I found a workaround: that workaround worked for a long time. But in December 2013 that workaround stopped working. That is having the text field changed to a password field is no longer effective. At that time, we adopted the workaround given by ice cream, which works, but loses control as it applies to all fields. Therefore, the new workaround provided by Nagendra should be tried, which could restore the granularity of being able to apply the workaround to just the password fields. Queuing up for dev; might be a while until we get to it.
    – Jeffrey Simon
    Commented May 20, 2014 at 14:36

3 Answers 3

Reset to default
2

It appears that Chrome now ignores autocomplete="off" unless it is on the <form autocomplete="off"> tag (which applies to the entire form). You used to be able to add the tag to any <input> field, which gave you a lot more control.

You may also need to start the document with this DTD:

<!DOCTYPE html>
Improve this answer
2
  • This might work but in the meantime I have the workaround described above. Plus have to use more complicated approach from Steven Ostermiller to allow autofilling elsewhere.
    – Jeffrey Simon
    Commented Apr 28, 2013 at 0:51
  • IMPORTANT! Please 'star' this chrome issue
    – cvsguimaraes
    Commented May 13, 2014 at 19:12
1

Put each field into its own form, and use nonsensical field names and ids. Then, onchange, use javascript to copy the contents to hidden fields in the main form.

<form name=fake1 onsubmit="return false" autocomplete="off">
    New Email Address: <input type=text id=xy1 name=xy1 onchange="document.mainform.newemail=this.value">
</form>
<form name=fake2 onsubmit="return false" autocomplete="off">
    Re-Enter Email Address: <input type=text id=xy2 name=xy2 onchange="document.mainform.confirmemail=this.value">
</form>
<form name=fake3 onsubmit="return false" autocomplete="off">
    New Password: <input type=password id=xy3 name=xy3 onchange="document.mainform.password=this.value">
</form>
<form name=fake3 onsubmit="return false" autocomplete="off">
    Confirm New Password: <input type=password id=xy4 name=xy4 onchange="document.mainform.confirmpassword=this.value">
</form>
<form name=mainform>
    <input type=hidden name=email value="">
    <input type=hidden name=confirmemail value="">
    <input type=hidden name=password value="">
    <input type=hidden name=confirmpasword value="">
</form>
Improve this answer
2
  • Seems like a potential approach, if my current workaround described in the comment to the original question stops working.
    – Jeffrey Simon
    Commented Apr 28, 2013 at 0:52
  • I finally got back to work on this. Removing the value attribute has no effect on the problem. I also tried this interesting test: put in some jquery to clear the field. What happens is that the field autofills, the jquery clears it, and then Chrome autofills it again!
    – Jeffrey Simon
    Commented Jul 25, 2014 at 3:35
1

I found a workaround for this. If the password html input tag has value attribute set to blank or empty string, then it will autofill irrespective of autocomplete tag. Hence if the password field is blank don't add value attribute to the tag.

ex: 

@if (string.IsNullOrWhiteSpace(Model.Password))
       { 
        //omit value attribute
        <input type="password" name="@(propName).Password" id ="@(propName)_Password" class = "name_form" />   
       }
       else
       { 
        //include value attribute with existing model value 
        <input type="password" name="@(propName).Password" id ="@(propName)_Password" class = "name_form" value = "@Model.Password"/>
       }
Improve this answer
1
  • As stated in an above comment, this workaround would be an improvment as it restores the granularity of being able to apply the feature on a per-field basis. Queuing this up for development, although won't get to it until resources permit.
    – Jeffrey Simon
    Commented May 20, 2014 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.