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
