Re: [whatwg] focus change inside keypress event handler

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

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

Make sense?

> 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 
https://bugzilla.mozilla.org/show_bug.cgi?id=167145

> 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 
mess.  ;)

-Boris

Received on Thursday, 29 October 2009 14:15:35 UTC