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

Re: [whatwg] focus change inside keypress event handler

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Tue, 03 Nov 2009 04:23:28 -0500
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: whatwg@whatwg.org, www-dom@w3.org
Message-ID: <op.u2ta1eyn1ejg13@sandra-svwliu01>
On Tue, 03 Nov 2009 03:26:05 -0500, Michael A. Puls II  
<shadow2531@gmail.com> wrote:

> On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II  
> <shadow2531@gmail.com> wrote:
>
>> I'll put together a new description with the changes to see if sounds  
>> good.
>
> O.K., this description might be better and sounds more like what Firefox  
> does for compat with the net:
>
> -------
> Fire 'keydown' first.
>
> The default action for 'keydown' is to set the acceptKeypress flag to  
> true. Using preventDefault() (either explicitly or implicitly through  
> return false) prevents the default action and results in the  
> acceptKeypress flag remaining false.
>
> Changing the focus from one object to another inside the 'keydown'  
> handler changes the current Context Object (what the action will be  
> performed on) for the following 'keypress' handler.
>
> After the 'keydown' handler runs, fire 'keypress'.
>
> The default action for 'keypress' is to allow the keypress if the  
> acceptKeypress flag is true.
>
> If acceptKeypress is not true or if preventDefault() is called in the  
> 'keypress' handler (either explicitly or implicitly through return  
> false), then the keypress is not allowed.
>
> If the keypress is allowed then perform the action on the current  
> Context Object. The action could be text insertion, text deletion,  
> scrolling etc.
>
> If the keypress is not allowed, then do not perform the action unless  
> the UA does not allow preventing the action, which in that case, perform  
> the action.
>
> Note that a focus change inside a 'keypress' handler does not change the  
> current Context Object for the keypress.
>
> If the a key is being held down and Repeat Processing is supported,  
> process the above over and over. (e.g. keydown -> keyup -> keydown ->  
> keyup)
>
> When the key is finally released, fire 'keyup'.
>
> However, note that if alert(), confirm() or prompt() is used inside a  
> 'keydown' handler and or inside a 'keypress' handler, whether 'keyup'  
> fires varies between implementations.
>
> Also note that alert(), confirm(), prompt(), setTimeout and  
> setInterval() inside the  'keydown' , 'keypress' and 'keyup' handlers  
> may result in some code inside the handlers running in a different order  
> than 'keydown' -> 'keypress' -> 'keyup'.
> -------
>
> That's how Firefox appears to work, in my words, from the outside  
> looking in.

I should also note that in the 'keydown' handler, if a focus change  
happens *after* an alert(), the focus change will not change the context  
for 'keypress' as 'keypress' will have already fired before the focus  
change happens, which probably makes my "After the 'keydown' handler runs,  
fire 'keypress'" part not entire accurate as far as "After" goes.

-- 
Michael
Received on Tuesday, 3 November 2009 09:24:07 GMT

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