Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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

share|improve this question
    
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 Apr 16 '13 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 Apr 28 '13 at 0:50
    
Why can't you just use the autocomplete attribute? Can't imagine what you need to be complying with. –  DisgruntledGoat Jun 10 '13 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 Jun 15 '13 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 May 20 at 14:36
add comment

3 Answers 3

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>
share|improve this answer
    
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 Apr 28 '13 at 0:51
    
IMPORTANT! Please 'star' this chrome issue –  cvsguimaraes May 13 at 19:12
add comment

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>
share|improve this answer
    
Seems like a potential approach, if my current workaround described in the comment to the original question stops working. –  Jeffrey Simon Apr 28 '13 at 0:52
add comment

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"/>
       }
share|improve this answer
    
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 May 20 at 14:52
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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