[whatwg] focus change inside keypress event handler

[Michael A. Puls II]

On Thu, 29 Oct 2009 20:51:48 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:

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

So, just to be sure, you're happy with that behavior?

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

O.K., will assume that 'keypress' always needs to fire then.

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

O.K. FF doesn't do that though. If you hold down a key, it'll do:
keydown
keypress

over and over.

At quick thought, are you O.K. with FF's current behavior being a bug?

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

Is there a good way to solve that though? Or is that something that should  
just be left as YMMV?

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

O.K., cool.

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

O.K., cool.

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

Understood.

I'll put together a new description with the changes to see if sounds good.

Thanks very much.

-- 
Michael