Log in

To The Side

When does form autocomplete happen?

Today for fixing a bug in Bugzilla I needed an event to fire only after the browser had automatically autocompleted the login form (what Firefox, Chrome, and Safari do when you have saved exactly one set of login credentials for a site). Most people would think that window.onload would work, and it does, in one browser--Chrome. Other people might try to use YUI's onDOMReady event, which fires when all the content is available in the DOM. That works in exactly one engine--Gecko.

The problem is that autocomplete happens at different times in different browsers, and you can't even rely on knowing what engine the browser is using--in WebKit-based browsers, it happens at different times depending on what browser is being used. Here's when autocomplete happens in different browsers:

  • Gecko: Before onDOMReady, but after window.onload (so use onDOMReady).
  • Chrome: After onDOMReady, but before window.onload (so use window.onload).
  • Safari: After both onDOMReady and window.onload (so do a 200 millisecond window.setTimeout on window.onload).
  • Opera: Never autocompletes forms without user interaction.
  • IE: Never autocompletes forms without user interaction.

So the only reliable solution is to fallback to the Safari solution, which is to do something 200 milliseconds after window.onload. I tried 100ms, and I was getting into race conditions where sometimes my event would fire before autocomplete, sometimes it would fire after. I upped it to 200ms as a safe amount.

This is a little annoying if you want something to happen instantly after the form is autocompleted, so what I actually did for Bugzilla was I fired the event after onDOMReady for Gecko, and used the Safari solution for all other browsers.

Anyhow, it would be nice if this was all standardized some day.


Tags: ,



A better way

Eventually, once browsers support it, the HTML5 "placeholder" attribute will be the preferred way to do this... See bug 457800.

Re: A better way

Oh, that would be very nice, yeah. :-)



'DOMContentLoaded' firing after 'load' doesn't make sense. So maybe YUI's onDOMReady is broken.
Um, possible. :-) I didn't look at the implementation. Maybe I forgot the actual order and they happened in a different order.

It may be a security issue, as an XSS or an Javascript Injection may help to stole password/hijack cookies/interact with evil behaviours.
Mmm, I doubt that would count as a security issue--if you can XSS or inject JS, you're vulnerable to that sort of thing in various ways anyhow.

I'm really surprised DOMContentLoaded isn't standard; it's immensely useful, often moreso than load.

Wikipedia says it's in Opera 9 and Safari 3.1 as well as Gecko, so I assume it's in WebKit and will make its way to Chrome and friends soon. No idea how onDOMReady works or if it tries to use DOMContentLoaded in WebKit browsers.
Yeah, I know. I do pretty much all the things that I used to do with load with onDOMReady now, because that's all I really care about anyway. I mean, for the most part who cares if the page has been rendered? I just want to know when I can mess with it all safely via JS.



Can you access the value of a password field onchange, and does onchange fire for form auto complete?

If so, how about a function that checks to see if the value of the password field is empty - if it is then it shows the place holder, if it is not then it shows the real field. The function could be called onload and onchange of the password field.

Re: OnChange?

When I was researching my issue, I saw several posts that mentioned that in at least IE, onchange doesn't fire for their form of autocomplete. I don't know if it fires for the automatic-autocomplete in FF, though.

The function you're describing is exactly the function that Bugzilla is already doing, and it's the "called onload" that's the problem. If there is already something in the field, the field will never be populated by automatic autocomplete, or in fact autocomplete of any form in any browser.


Re: OnChange?

I know it doesn't help bugzilla much, but I would consider that a bug in the browser, at least for post-load autocomplete. The form field had one value, now it has another - it has changed, so onchange should fire.

Its a bit more complicated for something that autocompletes as the page is loading though - did the field change, or did it have the autocompleted value when it was created? (ignoring implementation issues which mean autocomplete normally actually happens well after a specific field has been displayed).

I guess all this begs the question of if these sorts of features should be part of a web specification. We can't really say one browser is doing something the wrong way if there isn't an agreed 'right' way and it is difficult to code against varying implementations.

Re: OnChange?

Yeah, I think that standardizing autocomplete behavior is probably the best solution to this particular problem. Whether or not it's worth going through the standards process in general for the feature, though, is a separate question.