W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

Re: [whatwg] focus change inside keypress event handler

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 30 Oct 2009 01:29:00 -0400
Message-ID: <4AEA799C.8090701@mit.edu>
To: "Michael A. Puls II" <shadow2531@gmail.com>
CC: whatwg@whatwg.org, www-dom@w3.org
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?

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.

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

-Boris
Received on Friday, 30 October 2009 05:29:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT