Re: [whatwg] focus change inside keypress event handler

I should add that if you want the the character to appear in the first input
field, then use keyup to redirect the focus (because it occurs after
keypress and the character insertion). The only caveat here is that it
assumes input from the keyboard (ex: a textinput event generated from
handwriting recognition would not be followed by a keyup event). But your
original question used keypress, so I'll assume it's safe to make this
assumption.

--Jacob


On Wed, Oct 28, 2009 at 10:57 AM, Jacob Rossi <rossi@gatech.edu> wrote:

> On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
> <shadow2531@gmail.com<shadow2531@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.
>
> --Jacob
>