- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Fri, 30 Oct 2009 18:41:34 -0400
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
Received on Friday, 30 October 2009 15:41:34 UTC