Watch out for Autocomplete

June 07, 2006

I ran into a funny problem today that had to do with the Autocomplete feature in Firefox. If I had autocomplete turned off on my computer it would have been very hard to debug this issue, but I quickly realized that autocomplete was the problem.

Suppose you have a backend app to manage users. You have a login for that looks like this:

<label for="username">Username</label>
<input type="text" name="username" id="username" />

Now if you also have an edit user form with the same code, autocomplete will fill in the username you used to login with into the username field. This is not a problem if your editing your own username, but if you want to edit someone else, then you have a problem.

So at first I thought I could fix this by changing the name attribute on the input tag, but this didn't work. You have to change the id attribute.

Another way to fix this is to set autocomplete="off" in your input tag. But that is a non standard attribute, and breaks HTML validation.

Related Entries

15 people found this page useful, what do you think?


Hi Pete, I just wanted to comment on the non-standard-attribute, autocomplete. I'm with Jakob Nielsen - - on this one. If an attribute is non-standard, then the browser shouldn't detect it, so it doesn't really matter. Of course, your code won't validate, but what is more important; using code that divert a bit from standard or making the application less user friendly? I stick to standards, but I do make a few exceptions - this is one of those.
Pete - we had a similar issue related to a browser's (IE, Firefox) ability to store passwords related to a username (not recommended, but so many people use it). They would sign in with their username and password, get into our system, change their password, then the next time they tried to sign in using the username, the browser would fill the password field with stars, but it was the password stored in the browser, not the new one in our db. So, of course, the login fails and the user is befuddled. It took us a while to track down the fact that so many users were complaining that they could not sign in after changing their password. They do not connect the browser storing the password versus the db storing it. We debated to try to implement strategies to disable the autocomplete (using different sign-in text fields), but did not want to break standard functionality. So if you have users complaining about not being able to sign in after changing their password, inform them to clear the stars at least once!
>not a problem if your editing your own username, this from the guy whose grammar cheatsheet mentions "you're" v "your" ?? he he.... no problem. which reminds me: "whose" v "who's" is a common problem...
You actually took the time to type that just to correct a grammar mistake? jeeze. :rollseyes: Anyway, I into the same problem at a former job. Instead of turning off autocomplete, we ran a script that would clear out the password for a certain domain and forced the user to type in the UN and PW once a month. Cut our service calls down a lot because it also forced the user to remember the UN and PW :-)
I had this same problem. There is another way around this issue as far as login is concerned. It is a little more complicated but it does the trick. #1 When a user signs up you should encrypt the password using md5 or the like and store the encrypted password in the database. #2 When the user logs in, store the encrypted password in a cookie. #3 On your login page, check for the cookie first and then redirect the user away from the login form directly into your restricted area. #5 Make sure you have a logout button that clears the cookies of the user. #4 On the login form, set your password field and body to something like this: <head> <script type="text/javascript"> function clearPass() { var pass = document.getElementById("user_Pass"); pass.value = ""; } </script> </head> <body onload="clearPass()"> /* FORM CODE HERE */ <input id="user_Pass" type="password" name="user_Pass" /> This is generally my way of controlling access without the complication of autocompletion. As for when you are editing a users password. Just change the javascript to say. From: pass.value = ""; To: (if you're using asp) pass.value = "<%=user_Pass%>"; (if you're using php) pass.value = "<?=user_Pass?>"; I hope this work as u expect. It is a hassle, but its what you need to do if you are a "Go Standards or Go Home" type of coder.
I've found that autocomplete="off" doesn't even work with firefox - its only for Mozilla / older gecko based browsers! I've even tried renaming input fields and id, but to no avail. There is only the XUL textbox attribute disableautocomplete="true", which isn't useful as its for the client side!
document.getElementById("password").setAttribute("autocomplete", "off"); Still xhtml compliant :)
Found this thread on google, and after working through some of the solutions on here (that Firefox blatantly ignores), I've discovered my own.

Simply place a hidden password field, with no name, at the start of your form - this seems to trick firefox into thinking that this is the main password field, but as there's no name it a) doesn't get set and b) doesn't get submitted!

It's genius.

Recent Entries