W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

Re: [whatwg] focus change inside keypress event handler

From: Scott González <scott.gonzalez@gmail.com>
Date: Thu, 29 Oct 2009 11:03:04 -0400
Message-ID: <9450c5340910290803r53e6747er721c4afcec182bc6@mail.gmail.com>
To: "Michael A. Puls II" <shadow2531@gmail.com>
Cc: Jacob Rossi <rossi@gatech.edu>, t.broyer@gmail.com, whatwg@whatwg.org, www-dom@w3.org
On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II <shadow2531@gmail.com>wrote:

> 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.

DOM Level 3 Events says "The default action of the keypress event depends
upon the key and the context: if the key is associated with a character, and
if there currently focused element in the document can receive text (such as
a form input or an editable text block), the default action is to dispatch a
textInput event with the character as the value of the TextEvent.data

The default action of a keypress is not to insert a character in the element
that has focus, but to insert a character on the element that represents the
context of the keypress. In the given example, the keypress's context is the
first field, not the second. I agree though that the documentation could be
clearer about this as it's not explicitly stated.
Received on Thursday, 29 October 2009 17:31:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC