[whatwg] focus change inside keypress event handler

[Michael A. Puls II]

On Fri, 30 Oct 2009 01:29:00 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 10/29/09 9:58 PM, Michael A. Puls II wrote:
>>>> 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?
>
> Which?  It being possible to change focus in keydown and thus change  
> where the text will go?

Yes.

> I'm pretty agnostic on whether that should be possible or not. Whichever  
> way makes the event model simpler, I think.
>
>>> 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?
>
> I don't know.  It's worth looking up why the behavior is as it is (that  
> is, what web sites depend on).  Multiple keypresses in this situation  
> are a definite necessity.

Thanks. Opera seems to get a way with the multiple keydowns. But, its user  
base isn't as large, so, I'm not sure how much weight that has.

>>>> 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?
>
> Well, you could require an alert to block all key event delivery to the  
> web page, right?

Would that be a desirable solution? Is that hard to implement?

-- 
Michael