onfocus after alert box.

[Jonathan N. Little]

As part of a JavaScript precheck form validation I noticed a problem
with trying to return focus to the field with an error. I have setup a
demo page.

http://www.littleworksstudio.com/temp/usenet/focus.html

To simulate the problem, just enter or change the "first" textbox and
either click or tab to another control., it is tied to the onchange
event. An alert box that simulates the "warning". When you close it the
focus will not move back to "first" except in Opera. IE nor geckos will
return the focus. Oddly, I also call 'select()' on the element and
geckos do fully select content in "first" but the cursor will be
wherever you tabbed or clicked to...

I have found a "fix" shown on the "second" textbox by adding a 1ms delay
to the focus. Not quite elegant. I assume it's an event bubble thing,
this used to work in <=v4 browsers.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO

http://www.LittleWorksStudio.com

[Thomas 'PointedEars' Lahn]

focus() after alert box (was: onfocus after alert box.)

Jonathan N. Little wrote:

http://www.littleworksstudio.com/temp/usenet/focus.html

>
To simulate the problem, just enter or change the "first" textbox and
either click or tab to another control., it is tied to the onchange
event. An alert box that simulates the "warning". When you close it the
focus will not move back to "first" except in Opera. IE nor geckos will
return the focus. Oddly, I also call 'select()' on the element and
geckos do fully select content in "first" but the cursor will be
wherever you tabbed or clicked to...
>
I have found a "fix" shown on the "second" textbox by adding a 1ms delay
to the focus. Not quite elegant. I assume it's an event bubble thing,
this used to work in <=v4 browsers.

The Subject you chose is imprecise; this does not have anything to do with
the `onfocus' event handler attribute/property; it has to do with the
focus() method of form control objects used in event listeners for the
`change' event. (It also has nothing to do with event bubbling as the
`change' event does not bubble in all DOMs.)

By definition, the "`change' event occurs when a control loses the input
focus and its value has been modified since gaining focus."[1] I would
presume that since focusing the control that the user just attempted to
leave would trap the user in that control which is not at all user-friendly,
a counter-measure implemented in user agents is not to do that and only
carry out what the select() call implies.

The "1ms delay" you speak of is instead a delay as long as the minimum
interval between timer ticks of the execution environments, usually 10 ms
and more. It would appear then that the developers of the user agent in
question do not regard this as an obvious attempt of script kiddie
programming as with calling focus() directly, and therefore carry out what
the delayed focus() call implies.

IMHO your approach is outdated and therefore no longer viable in current
user agents of which most appear to favor usability for good reasons. You
should not bother your users with alert message boxes whenever they leave a
control that does not have a fitting changed value. Instead, you should
show them a block element indicating the problem with the value if
supported, and validate both on form submission if feasible (where you can
use *one* alert message box and focus the first offending control after it
was confirmed) and always server-side later.


HTH

PointedEars
___________
[1]

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Jonathan N. Little]

Re: focus() after alert box

Thomas 'PointedEars' Lahn wrote:

Jonathan N. Little wrote:

>http://www.littleworksstudio.com/temp/usenet/focus.html
>>
>To simulate the problem, just enter or change the "first" textbox and
>either click or tab to another control., it is tied to the onchange
>event. An alert box that simulates the "warning". When you close it the
>focus will not move back to "first" except in Opera. IE nor geckos will
>return the focus. Oddly, I also call 'select()' on the element and
>geckos do fully select content in "first" but the cursor will be
>wherever you tabbed or clicked to...
>>
>I have found a "fix" shown on the "second" textbox by adding a 1ms delay
>to the focus. Not quite elegant. I assume it's an event bubble thing,
>this used to work in <=v4 browsers.

>
The Subject you chose is imprecise; this does not have anything to do with
the `onfocus' event handler attribute/property; it has to do with the
focus() method of form control objects used in event listeners for the
`change' event.

Thank you for the clarification.

(It also has nothing to do with event bubbling as the

`change' event does not bubble in all DOMs.)

Just a WAG, that was why I was asking?

>
By definition, the "`change' event occurs when a control loses the input
focus and its value has been modified since gaining focus."[1] I would
presume that since focusing the control that the user just attempted to
leave would trap the user in that control which is not at all user-friendly,
a counter-measure implemented in user agents is not to do that and only
carry out what the select() call implies.
>
The "1ms delay" you speak of is instead a delay as long as the minimum
interval between timer ticks of the execution environments, usually 10 ms
and more. It would appear then that the developers of the user agent in
question do not regard this as an obvious attempt of script kiddie
programming as with calling focus() directly, and therefore carry out what
the delayed focus() call implies.
>

Maybe, if universally applied. My usage is conservative, and restricted
to required fields. As with all my JavaScript the intention, it only
augments the process, all will function without it. My real validation
is done server side. It was just meant as a convenience, if JavaScript
is availably, to help direct the user to where the error has occurred.

The 1ms was only the minimum that I found to work, that is all. To
illustrate the difference in an attempt to understand the situation.
Also hence why I am asking the question here.

IMHO your approach is outdated and therefore no longer viable in current
user agents of which most appear to favor usability for good reasons. You
should not bother your users with alert message boxes whenever they leave a
control that does not have a fitting changed value. Instead, you should
show them a block element indicating the problem with the value if
supported, and validate both on form submission if feasible (where you can
use *one* alert message box and focus the first offending control after it
was confirmed) and always server-side later.

You might be correct. Legacy can cause certain "features" to persist in
existing pages. Since I already have a mechanism to color the error
fields (both client and server side) it would probably not be to
difficult insert the warning message after the error field instead of in
an alert. Convey the information without the disruptive modal dialog. I
will explore an alternative. Out of curiosity I do wish to understand
the cause and the difference between "first" and "second" in my demo.

What is to be avoided are those online form that reject you but give
little or no indication what the problem is and how to correct it. But
also I have found with years of experience in online commerce, that
sometimes no amount of clear instruction or assistance can help some
users...


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO

http://www.LittleWorksStudio.com