[whatwg] focus change inside keypress event handler

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

Received on Thursday, 29 October 2009 06:20:24 UTC