[whatwg] focus change inside keypress event handler
Boris Zbarsky
bzbarsky at MIT.EDU
Thu Oct 29 17:51:48 PDT 2009
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
More information about the whatwg
mailing list