Alert and Input Control Events

Dear JavaScripters:

Does using alert() cause input control events to fire?

I am writing some validation routines where I want the control to
keep the focus if the test fails. (Yes, I know that this is
desktop-app style. That is what I want.)

Actually, if onblur fires, the focus has already moved. To get
around this, I have a global that is set if validation is already
occurring on another input control. In that case, I simply bypass the
validation on the second control so that the focus can be set back.

This works (IE 9 & Windows 7).

It seems that the order of statements is important. I have to
set the focus back before generating the error alert. Otherwise, it
does not work right, and I can get the other input control's
validation routine getting in the way. I also had the hilarity of my
debugging alert() statements affecting the program flow.

It seems to me that alert() might cause input control events to
fire. Is this so? If so, is it guaranteed to be like this, or is it
just IE 9's implementation? How tied to implementation is this error
handling making my code?

Sincerely,

Gene Wirchenko

On 2011-12-30 00:28, Gene Wirchenko wrote:

Maybe. A word of caution, though: don't try too hard to control the
users' focus:

1) you can still deny the submission of an incorrectly filled-out
form later on,
2) you can't control the focus reliably across different platforms,
anyway, and most imporantly
3) there may be a good reason why the user wants the focus somewhere
else

What you describe is pretty much the way the forms in one of my projects
worked (by customer request) up until a few years ago. Then it turned
out that this behavior was perceived as more of a hindrance than a help.
It's usually better to visually mark the field as invalid and let the
users fill out the other fields in the order they want to.

A trivial (and admittedly construed) example where gluing the focus to
one particular field would be harmful is a 3-field date input:

[2011] [11] [30] (pre-filled values)

The user realizes that the correct value should be 2011-12-31, and
starts by changing the "day" field, entering "31". This results in a
temporarily invalid date - but they can't leave the "day" field to
adjust the "month" field. They will swear at the "stupid braindead app",
click away the alert, enter "30", change the month, and finally enter
"31" again.

Now we just let them fill out invalid values as they like, color the
respective field labels red, and wait until they try to submit the form
before we show any alerts or change the focus.


Yup, it can do that :)
Especially when events and/or timeouts are involved. Using console.log()
for debugging gets rid of all that.


Sorry, I can't help there (my experience with IE is rather limited).
I realize that what I wrote doesn't have much to do with JS per se, and
I didn't answer your original question, but maybe this helps anyway.


- stefan

On Sat, 31 Dec 2011 01:27:32 +0100, Stefan Weiss
<krewecherl@gmail.com> wrote:

[snip]

^^^^^^^^^^^^^^^^^^
Yech!


I am referring to field-level validation, not form-level
validation. If a field value itself is invalid *without reference to
any other fields*, I will throw an error. In the above example,
entering a month 13 is such an error. Entering a day 32 is such an
error. Entering a day 31 is not such an error.

If the problem is that two or more field values are incompatible
(say, month 2 and day 30), that is a form-level error and I would
handle that on form submit.

The principle is to catch the error as soon as possible.

[snip]

Sincerely,

Gene Wirchenko

Am 2012-01-01 08:40, Gene Wirchenko meinte:


Do you *really* want to use alert dialogs for such errors (and fiddling
with element focus)? Usability will be painful, to say the least. Even
more so, when there will be a second validation run upon submission
(with probably a different way to inform the user about errors). I'd opt
for blur listeners giving consistent feedbacks, and *not* fiddling with
element focus.

Gregor