[whatwg] focus change inside keypress event handler
bzbarsky at MIT.EDU
Thu Oct 29 07:14:42 PDT 2009
On 10/29/09 9:20 AM, Michael A. Puls II wrote:
> 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
Last I checked in Gecko, things looked somewhat like this:
Editors (those editable things inside text inputs) set up some default
actions (effectively event listeners in the system event group). The
default keypress event action is to enter the character.
When you press a button on your keyboard, the focus is used for one
thing and one thing only: to decide where to dispatch the key events.
So the keypress event is dispatched to the thing that has focus. If one
of the event handlers for keypress changes what has the focus, that
doesn't change where the default action of the keypress event takes
place (since the event target chain is built completely before any of
the event handling takes place).
> 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.
You might be interested in
> 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?
These are all excellent questions that the spec should answer.
> 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)
This is two separate questions:
1) When is the 'd' actually inserted?
2) When is the element the 'd' will be inserted in determined?
In Gecko, the answers are effectively:
1) During the default action phase of the keypress event,
assuming that it has not had preventDefault() called via
various mechanisms (e.g. preventDefault() on keydown will
trigger preventDefault on all resulting keypresses in Gecko).
2) Immediately before the keypress event is fired.
(two sides of the same coin, really, since this is just how default
actions work in DOM event land).
> 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.
Yep. And you could use script to set .value at various points in there,
leading to fun questions about how onchange should work, too. It's a
More information about the whatwg