Coding Around Browser Bugs

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:

  1. Add a bunch of code into your application to work around the problem.
  2. 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 :scare: working :/scare: at all. 🙂

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.

  1. Except for not providing a more friendly error message, now fixed. [up]
  2. 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]
  3. 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]
  4. 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.