Re: [whatwg] focus change inside keypress event handler

On 10/29/09 5:24 PM, Michael A. Puls II wrote:
> I think so. The event target isn't changed by focus().
>
> But, in Firefox, Safari and Opera, it's possible to change what element
> the text is inserted into by changing the focus in 'keydown'.

Right; that happens because the keydown and keypress events need not 
fire on the same element and because the text entry is the keypress 
default action.  In Gecko, that is.  I can't speak to Safari and Opera.

> 'keydown' fires first.
>
> If a handler for 'keydown' calls preventDefault() (explicitly or
> implicitly via returning false), do not fire 'keypress' after the
> 'keydown' handler returns.

No.  That breaks sites, at least in our experience (as described in 
https://bugzilla.mozilla.org/show_bug.cgi?id=167145).

> If the key is being held down, 'keydown' or both 'keydown' first and
> then 'keypress' second will fire repeatedly according to the rules above.

This seems wrong to me.  If a key is held down, I would expect a single 
keydown followed by multiple keypresses.

> Note that 'keyup' may fire before 'keypress' if you release the key
> before an alert() inside the 'keydown' handler shows and blocks.

This seems unfortunate, but ok.

 > When holding down a key, it just repeatedly fires
> 'keypress', instead of just 'keydown' or both 'keydown and 'keypress'
> like Firefox and Safari.

That behavior makes a lot of sense to me, actually.

> As for Firefox, it's different too in that preventDefault() doesn't stop
> any events from firing. It just stops text insertion in some cases.

Yes. We found that to be necessary for web compat.

> Ultimately though, the spec should define all this stuff clearly in a
> way that all browsers can implement.

Yes, though there might be some interesting differences here modulo what 
events the browser's host environment supports...

-Boris

Received on Friday, 30 October 2009 00:52:28 UTC