[thelist] More on IE onChange/autocomplete issue

[John.Brooking at NA.SAPPI.COM]

Howdy!

   I'm new to theList. I found it the other day when I was searching for
information on IE's "feature" of not firing the JavaScript onChange event
when a field is populated by auto-complete, which was discussed by Joshua,
Hershel, and Jeff back on July 16-17. Not to beat a dead horse, but I did
some more thinking and testing concerning the various work-arounds, and
though people may be interested in hearing about, and maybe responding to,
what I came up with. If you are not, you can skip the rest of this message.

   First, the MS page referred to by Hershel [1] mentions a third
work-around, which is to turn off auto-complete for that form: < form
autocomplete="off" >. Although it may possibly inconvenience the user, if
the form contains commonly-named fields which the user has completed before,
it is certainly the simplest solution for the developer.

   As has been noted previously by Joshua and Jeff, there are various
disadavantages to either of the other two solutions.

   As noted by Jeff, using onBlur instead of onChange has the potential for
infinite loops if you are not careful, via your onBlur handler calling
focus() when the element you are otherwise moving to may also have an
onFocus or onBlur itself. The only situation which I can think of where you
might be tempted to do this is if you are validating the field, and want to
keep the focus there if it is not valid. But the Right way to do this, in my
humble experience, is to call a validation function which returns a true or
false value, and pass that value back to the system. A false value on an
event generally cancels that event. In this case, it will prevent the blur
from completing, keeping the focus where it is without involving any other
fields, and without the need for explicit focus() command. So unless anyone
can think of another good reason to use focus() on an onBlur, maybe this
would go a long way to ameliorate that concern.

   Jeff's point about onBlur firing if the window itself loses focus is a
good one, and one that I can't think of a good way around, so that's
definitely a concern.

   Another disadvantage to onBlur which hasn't been mentioned is that my
most frequent use of onChange is to record somewhere that the value has
changed. Often this is when I have a large-ish form feeding a database, and
I don't necessarily want to reset all the fields if only one or two have
actually changed. Using plain onBlur, if a keyboard-savvy user starts from
the first field and tabs through all of them, changing nothing, they will
still all get marked for update. The alternative, adding code to figure out
if the current value is actually different from its previous value, sounds
like a pain in the butt, and I've never attempted it.

   On the other hand, my inclination to elegance chafes at having on
onPropertyChange in addition to an onChange for every field where used. Not
only that, but "value" is only one of the properties whose change could
trigger the onPropertyChange event. Although it is probably the most common
change, and maybe the only one in most forms (unless you are changing
background colors dynamically or something like that), best practices would
dictate that you check to make sure it's the "value" property that has
changed and not some other one, which means now you add another function to
check this before going on to call whatever function onChange normally
calls. Yuck.

   Worst of all, my experimentation shows onPropertyChange firing *after
every keystroke*, like onKeyPress, not just when leaving the field. Thus, it
is not necessarily interchangeable with onChange.

   My conclusion: I turned auto-complete off in the form. :-) Comments?

- John Brooking

[1]
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/aut
ocomplete_ovr.asp
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/au
tocomplete_ovr.asp> 

P.S. Sorry about the long disclaimer below. It is appended automatically by
my company, and their firewall also prevents me from using browser-based
email.

This message may contain information which is private, privileged or
confidential and is intended solely for the use of the individual or entity
named in the message. If you are not the intended recipient of this message,
please notify the sender thereof and destroy / delete the message. Neither
the sender nor Sappi Limited (including its subsidiaries and associated
companies) shall incur any liability resulting directly or indirectly from
accessing any of the attached files which may contain a virus or the like.