Browsers are getting better all the time. Those being worked on in the open source community like the Mozilla family of products are getting better every day. Add to that browsers like Apple’s Safari (which is based on the open source KHTML rendering engine) and the collective browsing experience is just getting better and better. Even Internet Explorer hasn’t been left too far behind with companies like Google developing free add-on toolbars offering functionality such as pop-up blocking.

One feature a lot of browsers seem to have (and offered by the Google Toolbar for IE) is Form Autofill. This useful utility allows you to enter a common set of information such as your name, email address and country, and then have the browser automatically fill out form fields based on that data. A real timesaver. But …

As web designers/developers we need to be careful. Typically, (I haven’t found one yet) form auto-fill features can behave a little unpredictably with the browser’s event layer. Namely, they don’t seem to fire JavaScript onchange events when they automatically fill out a form field.

Why is this a problem? On complex forms, we often try to simplify the filling-out process by adapting the form based on responses collected. For example, different countries have different postal address standards. What you call a ZIP code, I call a Postcode. Friendly forms may monitor the country field, and when a selection is made alter the label for the ZIP code field to read favourably to the user. This process uses an onchange event on the country field. Of course, that’s just one simple example – there are literally hundreds of common, more complex uses for onchange with forms dealing in common information.

If the user makes use of their browser’s form autofill feature, these onchange events don’t fire and the form can be left in a crippled state. I saw an example today where selecting a value in one field un-disabled the appropriate fields further down the form. As no onchange event was fired, all the fields remained disabled and the form was useless.

This isn’t particularly the fault of web developers. You can develop in a responsible way and still fall fowl of this. It’s good practice not to rely on JavaScript being available, and so what most of us do is to design forms to work fine without JavaScript, but to have additional helpful features if it is available. For example, if you want to have (and this is a daft example) a D.O.B. field disabled until the user has entered their email address, you would perform that disablement with JavaScript as the page loads. You would then use an onchange event to re-enable the D.O.B. field when an email address was entered. This way, if the user didn’t have JavaScript enabled in their browser the field would never have been disabled in the first place – therefore no problem to the user. As developers we pretty much bank on the fact that if we have the capability to do something, we have the capability to undo it. That’s not unreasonable. The problem arises where we use JavaScript to disable the D.O.B. field but the browser autofills the email field and doesn’t fire the onchange event to re-enable it.

So what can we do? Basically we can’t rely on the onchange event for the moment. I’m going to see if I can find an email address for the Toolbar people at Google and see it they have the problem on their radar or can even do anything about it within the scope of the IE framework. Ideally, I’d like to see autofill features firing the appropriate events, but secondarily it would be helpful if we could switch off autofill with a meta tag for important forms.

Whatever happens moving forward, it’s not really that much of a big deal – in fact it’s very much in the nature of the web. To be a good developer you have to learn that you can’t rely on the environment under which your page will be run. What you do need, however, is the ability to probe that environment in a useful way to find out what you can and can’t do. At the moment I don’t think we have that ability with autofill.