I got a support e-mail yesterday from a customer who ran into a nasty problem in the latest beta of Tasks Pro™. Whenever he went to edit another user in the admin interface, none of the settings he changed were saved and he got a duplicate key error message on the screen. Nasty bug right? Definitely. Unfortunately, Tasks Pro™ was working exactly as it was supposed to1.
Turns out, the auto-fill behavior of his browser (Firefox in this case) was setting the Username field in the form (for the other user) to his own username. Then when he tried to save, Tasks Pro™ (actually MySQL) was aborting the save and complaining because usernames need to be unique (you can’t have 2 users with the same username)2. Yuck!
What is a web developer to do when specific browser behavior causes problems like these? As far as I can tell, there are 2 options, and neither is very good:
- Add a bunch of code into your application to work around the problem.
- Ignore the problem and blame the browser.
The problem with option #1 is the never ending cycle of it all. I already have browser specific over-ride stylesheets and code in various places to handle various browser rendering quirks, but this specific problem goes deeper. To handle this, field names need to be sufficiently unique3 to break the browser auto-fill behavior. Of course, the next bug reported will be that my pages break the browser’s auto-fill behavior. Regardless, it’s a lot of thought and code4 going into something that I really shouldn’t be worrying about.
So what if I take option #2 and send a canned response to my users explaining that this is a browser behavior and how to work around it? Well, first off it doesn’t solve the “Hey, this doesn’t work” customer experience problem. Secondly, some customers won’t understand the explanation and become frustrated; and thirdly I still lose time dealing with the support e-mails.
Add on to this the fact that each browser has their own set of quirks, bugs and custom behavior and it’s amazing we get anything working
I tend to fall into camp #1, but this problem is a little more complicated than just adding a certain style attribute for a specific browser. In this case, I’d need to make changes to a complex form and to the way I process the information on the back end. It’s not the sort of change I relish making this late in the beta cycle of a new release.
I welcome your thoughts in the comments.
- Except for not providing a more friendly error message, now fixed. [up]
- Tasks Pro™ already checked this and returned a friendly error message when creating new users, but not when updating existing users. It now (next beta release) does check this and handle it gracefully. [up]
- One method is to add a unique ID prefix or suffix to the name of each field, then pass in that ID and strip it from each fieldname in the server side code. Not an optimal solution. [up]
- Also, extra code means more places for bugs to hide out. [up]
This post is part of the project: Tasks Pro™. View the project timeline for more context on this post.
I have run into this in a number of applications, and I have turned off that feature when necessary.
Administrators should never use auto-completion features when it comes to userdata.
Certainly not ideal, but would adding the autocomplete=”off” attribute to the form help in this situation?
It might help in this situation, but it’s a bandaid. Do I have to keep reacting to every new browser “feature” like this? Maybe I do… I dunno.
Here is a good thread on disabling auto-complete.
Agreed – not a great solution.
The only place I have seen this commonly used is on financial websites where they try to make sure that the user’s machine doesn’t inadvertantly store your username and pin.
Disable Auto complete in the form.
from
http://javascript.we[...]00130021541/
That’s nice (and already suggested above), but you’re either missing or ignoring the larger issue here.
Auto-Fill Behavior
Moving from the big picture to the small picture, I gave the current auto-fill behavior of the browser a little more thought. I think I would consider aspects of the current implementation to be a bug.
I consider features that can easily cause you t…
You know what *really* sucks?
I have this bug in 1.2.1, and for the first time in ages, it actually was solved by switching to IE to edit users.
*Shudder.*
God, that’s not good.
Jonathan