Event order of blur and change
I’m in the middle of fighting a battle with the blur and change events on a textbox. The requirement is simple: if the text changed in the textbox after losing focus, do one thing; if the text hasn’t changed when the textbox loses focus, do something else. This led me to an experiment to determine how blur and change events affected each other.
My initial assumption was that change would fire first since it’s a combination of a value change and blur, so if I prevented the default behavior of change that should effectively kill the blur event. I tested this hypothesis in Internet Explorer and found this to be the case. The change event fires first and, when the default action is prevented, it stops the blur event from firing. Thinking I had solved the problem, I did a quick double check in Firefox…naturally it didn’t work.
In Firefox, the blur event fires before the change event, so preventing the default behavior of change does nothing. A quick check of Opera 9 showed the same result as Firefox, thus indicating that Internet Explorer is probably the faulty implementation.
The specification states that neither blur nor change can be canceled and that only change bubbles, but doesn’t seem to provide any guidance on how the two should interact (if at all). I’m wondering who, then, has the correct implementation and who has the incorrect one? Does majority rule in this case?
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
3 Comments
I wrestled with blur and change events recently and finally decided that change is unreliable for the same reason you’ve stated. I’ve found that, if you need to detect a value change, it is better to rely on a blur event and write your own code to detect the change. I’m assuming that you’re using IE7? Too bad they didn’t fix that, but then again, I think it’s good practice to not rely on raw event order alone, especially with mouse events, focus, blur and change.
Patrick Fox on February 6th, 2007 at 9:48 pm
Second that Patrick — change will drive you looney…it’s been a while and we were only working with IE6, and it still didn’t behave consistantly. So we did exactly that, had the blur check if the value changed and things were better….but it still wasn’t good. So we wrote keyups to evaluate everything and keypresses for input criteria. Real shame they didn’t do much in IE 7…but if there’s any confort here, I’ve been dealing almost exclusively with Eclipse SWT Rich Clients…same issues.
Mike Shaffer on February 6th, 2007 at 10:26 pm
It seems that IE might actually make the best sense according the specification. If only the change bubbles, it would make sense that blur would not fire first since it wouldn’t bubble the event to the change.
If that’s the case, then it seems Firefox and Opera fire two separate events or are violating the specification by allowing blur to bubble the event.
Andrew Herron on February 7th, 2007 at 9:34 pm
Comments are automatically closed after 14 days.