[whatwg] focus change inside keypress event handler
Michael A. Puls II
shadow2531 at gmail.com
Thu Oct 29 06:20:24 PDT 2009
On Wed, 28 Oct 2009 10:57:43 -0400, Jacob Rossi <rossi at gatech.edu> wrote:
> On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
> <shadow2531 at gmail.com<shadow2531 at gmail.com?Subject=Re%3A%20%5Bwhatwg%5D%20focus%20change%20inside%20keypress%20event%20handler&In-Reply-To=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E&References=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E>>
> wrote:
>> (CCing DOM list just in case anyone there has any comments)
>>
>> With:
>>
>> <p><input onkeypress="this.nextSibling.focus()"><input></p>
>>
>> , if you type a character in the first field, should the character be
>> entered in the second field or the first?
>>
>> In Firefox and Safari, it's the first field. In IE and Opera, it's the
>> second.
> [...]
>> I do think FF and Safari's way makes more sense and I think most will
> agree.
>
> The keypress event is similar to textInput. Their intent is to indicate
> when character data has been entered. textInput is more powerful and
> captures character input from a number of input sources (keyboard, IME,
> voice, etc). In both cases, I would consider the default action to be the
> insertion of the characters into the DOM. For *most* events, the default
> action isn't performed until after event dispatch. Accordingly, I would
> expect that calling focus() during the dispatch of the keypress (or
> textInput) event would result in moving the cursor prior to the character
> data being inserted (because events are synchronous). Thus I think it
> makes
> most sense for the character to appear in the second input box.
>
> Another reason why this should be the case is what happens when you
> cancel
> the default action (call preventDefault() ). Canceling a textInput or
> keypress event should prevent the character from being inserted. So
> that's
> further evidence that the character insertion should happen after
> dispatch
> of the event.
Thanks. That makes sense technically.
Safari and Firefox will allow focus() inside the handler to decide where
the character gets inserted, but only with "keydown". With "keypress" (and
textInput in webkit) in Firefox and Safari, it appears that the char was
already inserted right after keydown, so a focus() change is already too
late. Despite that though, preventDefault() still works in Firefox and
Safari inside a "keypress" handler to prevent the char from being
inserted. So, I'm not exactly sure what's they're doing behind the scenes.
Note that Opera for example doesn't allow preventDefault() to have any
effect in the keydown handler. It only works in the "keypress" handler
more like you expect.
For clarification, if I press 'd' in the first input of:
<p><input><input></p>
<script>
window.onload = function() {
var inp = document.getElementsByTagName("input")[0];
function test(e) {
alert(e.type);
}
inp.addEventListener("textInput", test, false);
inp.addEventListener("keydown", test, false);
inp.addEventListener("keypress", test, false);
inp.addEventListener("keyup", test, false);
};
</script>
1. What order do those fire in?
2. What ones can you use preventDefault() in to stop the character from
being inserted?
3. For each one that you can use preventDefault() in to stop the insertion
of the 'd', if you use preventDefault(), which of the others will not fire?
4. When is the 'd' actually suppposed to be inserted (what the spec says,
not necessarily what browsers do)? (This will help determine what handlers
you can use focus() in to change what field the typed char gets inserted
in)
Also:
5. What are the list of keys that trigger keydown? (or do not if that's
easier)
6. What are the list of keys that trigger keypress? (or do not if that's
easier)
7. What are the list of keys that trigger keyup? (or do not if that's
easier)
8. For HTML5 and the 'input' event, if I add another lineto the above,
inp.addEventListener('input', test, false), when does 'input' fire? Before
the others? After the others? Does #3 apply here?
Basically, if anyone can describe in words all the steps that should
happen with the example code above, that'd be great. (If it's even defined
anywhere)
Thanks
In short though, browsers don't agree on this stuff and it's difficult to
decide what the right thing to do is in regards to "how it's supposed to
work". I could even throw other events that detect modification of the
fields value to complicate things even more.
--
Michael
More information about the whatwg
mailing list