Keyboard test page updated
in [JavaScript]
|
From: David Mark on 27 Jul 2010 21:27 On Jul 27, 9:06 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jul 27, 4:58 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > > > On Jul 27, 4:25 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > On Jul 27, 1:52 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > On Jul 27, 1:31 am, Adam Harvey <use...(a)adamharvey.name> wrote: > > > > > > On Sun, 25 Jul 2010 22:08:43 -0700, David Mark wrote: > > > > > > Looks good to me at this point, having tested numerous browsers released > > > > > > this century (and one released in the last). Of course, I only have a > > > > > > US keyboard and at the moment cannot test on a Mac (and have never been > > > > > > able to test on Unix of any sort). I know there are lots of variations > > > > > > and can't imagine that my logic handles them all. At this point I am > > > > > > open to observations and the inevitable workarounds. But I'm sure as > > > > > > hell not using any browser sniffing. :) > > > > > > Not that I think there'll be an awful lot of value in trying to handle a > > > > > lot of this, since it's decidedly unusual, but for the record, here are > > > > > some results on Ubuntu Linux 10.04. I have a Sun Type 7 keyboard, which > > > > > has some extra keys over and above a normal PC keyboard. > > > > > Okay. > > > > > > First, Chrome 6.0.472.0 dev (the current development release): > > > > > I'd really prefer to stick to general release versions, but no > > > > matter. :) > > > > > > All additional keys (Stop, Again, Copy, Paste, et cetera) return key code > > > > > 0: > > > > > Yes, I think we saw a bit of this in previous follow-ups. Clearly > > > > those are useless for browser scripting. > > > > > > Key down at test1: 0 > > > > > Key up at test1: 0 duration: 47 > > > > > > Others work pretty much per other operating systems. Holding down right > > > > > arrow, for example: > > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key up at test1: 39 duration: 867 > > > > > > Shortcut key (Control-X, in this case): > > > > > > Key down at test1: 17 > > > > > Key down at test1: 88 > > > > > Shortcut character at test1: "X" > > > > > Key up at test1: 88 duration: 48 > > > > > Key up at test1: 17 duration: 120 > > > > > Fair enough. > > > > > > One interesting case: I have a compose key [0] on the keyboard. (I find > > > > > it useful enough that I tend to bind right-alt to compose on my PC > > > > > keyboards as well, but this one happens to be actually labelled compose.) > > > > > I've heard of that, but have never owned such a keyboard. > > > > > > Using it to enter, say é requires three key presses: Compose; '; e. That > > > > > looks like this: > > > > > > Key down at test1: 229 > > > > > Key down at test1: 229 > > > > > Key up at test1: 0 duration: undefined > > > > > Key up at test1: 222 duration: undefined > > > > > Key down at test1: 69 > > > > > Character at test1: "é" (233) > > > > > Well, at least the character came through unscathed. :) > > > > > > Key up at test1: 69 duration: 61 > > > > > > The same tests, on Firefox 3.6.8: > > > > > > Extra keys behave the same: > > > > > > Key down at test1: 0 > > > > > Key up at test1: 0 duration: 38 > > > > > Good to be consistent. > > > > > > Holding right arrow results in slightly different log output: > > > > > > Key down at test1: 39 > > > > > Autorepeat model: press > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key down at test1: 39 > > > > > Key up at test1: 39 duration: 750 > > > > > Perfect! The extra log entry indicates that specific type of auto- > > > > repeat behavior for control keys has been detected. That's the one I > > > > have always seen in FF on Windows. > > > > Update, actually "both" is what I'm used to see in FF on Windows. > > > Opera on Windows is the one with the "press" model. Wouldn't shock me > > > if there is a cross-platform deviation there. As long as the auto- > > > repeated control keys work, all is well. :) > > > > Just fixed the one issue noted in the document (backspace auto-repeat > > > in IE). Re-testing and will update shortly... > > > Posted. > > Wrapping up the canned My Library version. Noticed one mistake in the > test page character counter demo. The onkey and onchar arguments were > transposed in the call to attachKeyboardListeners. Wasn't fatal, but > was definitely inefficient. ISTM I had noted at one point that Opera > wasn't updating the count until auto-repeated characters stopped. > That was why. > Fixed. Looking at the Character Counter demo, I see it is really too clever for its own good. Besides the tabs, what's wrong with this picture? CharacterCounter.prototype.onkey = function(e, keyCode) { if (keyCode == 45 || keyCode == 46 || keyCode == 127) { this.update(); } }; CharacterCounter.prototype.onchar = function(e, charCode) { this.update(); }; CharacterCounter.prototype.onshortcutchar = function(e, charCode) { var that = this; if (!charCode || charCode == 86 || (charCode > 87 && charCode < 91)) { // Clipboard, undo/redo operations may not have completed yet window.setTimeout(function() { that.update(); }, 1); } }; Really, really fast; but not necessarily 100% accurate cross-browser/ platform. Still, er, show me where it fails. :)
From: Nisse Engström on 28 Jul 2010 08:41 On Mon, 26 Jul 2010 15:27:04 -0700 (PDT), David Mark wrote: > On Jul 26, 1:24 pm, Nisse Engström <news.NOSPAM.id...(a)luden.se> wrote: > >> Also, when Num Lock is off, "7" is intercepted >> by Opera and produces: >> >> Key down at test4: 36 >> Key down at test4: 0 > > That's the "Home" key on the numeric keypad. On XP I get:- > > Key down at test1: 36 > Key up at test1: 36 duration: 131 > > So something odd is going on there in Windows 98. Oops! I forgot that the "7" key on the numeric keypad is flaky. It frequently activates the context menu, which I believe is what happened here. Sorry about that. Blame my caffein addiction. >> Most Alt-Gr combinations work fine, eg: (Note: That should have been "AltGr", eg. a single key.) >> Key down at test4: 18 >> Key down at test4: 187 >> -> Shortcut character at test4: "»" > > Aha! There's a bug. I neglected to disallow "shortcut characters" > when the altKey flag was set. Fixed! > >> Character at test4: "\" (92) >> Key up at test4: 187 duration: 97 >> Key up at test4: 18 duration: 325 >> >> Key down at test4: 18 >> Key down at test4: 194 >> -> Shortcut character at test4: "â" > > Same bug. Please try these two again. > >> Character at test4: "|" (124) >> Key up at test4: 194 duration: 107 >> Key up at test4: 18 duration: 325 Key down at test2: 17 Key down at test2: 18 Key down at test2: 187 Character at test2: "\" (92) Key up at test2: 187 duration: 124 Key up at test2: 18 duration: 324 Key down at test4: 18 Key down at test4: 187 Character at test4: "\" (92) Key up at test4: 187 duration: 117 Key up at test4: 18 duration: 350 Key down at test2: 17 Key down at test2: 18 Key down at test2: 194 Character at test2: "|" (124) Key up at test2: 194 duration: 97 Key up at test2: 18 duration: 265 Key down at test4: 18 Key down at test4: 194 Character at test4: "|" (124) Key up at test4: 194 duration: 50 Key up at test4: 18 duration: 279 >> Escape: Only works once per page load. >> >> Key down at test4: 27 > > In Opera, in a text input, that key causes the input to lose the > focus. Canceling the keypress will prevent that and allow the keyup > to come through. As with the arrow keys and PageUp/Down, it appears I > need to add Esc to the list of keys handled by the onNavKeyPress > callback. > > Also, which sets of inputs are you testing? The now deprecated ones (because they were closer to the log). > The other two inputs fire the keydown event for each press of the > escape key (though never keyup as focus is lost immediately). That is > the expected behavior. Confirmed. >> Modifiers keys: >> --------------- > > Again, I assume you are testing the second set of test inputs, which > attempt to prevent duplicate control keydowns. You shouldn't have > this problem on the first two. Ctrl AltGr AltGr Ctrl: [1st set] Key down at test2: 17 Key up at test2: 17 duration: 112 -> Key down at test2: 17 Key down at test2: 18 Key up at test2: 18 duration: 48 -> Key down at test2: 17 Key down at test2: 18 Key up at test2: 18 duration: 101 Key down at test2: 17 Key up at test2: 17 duration: 55 [2nd set] Key down at test4: 17 Key up at test4: 17 duration: 109 -> Key down at test4: 17 Key down at test4: 18 Key up at test4: 18 duration: 94 Key down at test4: 18 Key up at test4: 18 duration: 66 -> Key up at test4: 17 duration: 1869 Shift AltGr AltGr Shift: [1st set] Key down at test2: 16 Key up at test2: 16 duration: 119 -> Key down at test2: 17 Key down at test2: 18 Key up at test2: 18 duration: 108 -> Key down at test2: 17 Key down at test2: 18 Key up at test2: 18 duration: 89 Key down at test2: 16 Key up at test2: 16 duration: 50 [2nd set] Key down at test4: 16 Key up at test4: 16 duration: 50 Key down at test4: 18 Key up at test4: 18 duration: 49 Key down at test4: 18 Key up at test4: 18 duration: 174 Key down at test4: 16 Key up at test4: 16 duration: 115 >> Cut/Copy/Paste: works fine and also generate key events. >> Eg.: >> >> Key down at test4: 17 >> Key down at test4: 86 >> Shortcut character at test4: "V" >> Key up at test4: 86 duration: -2 > > I'm not sure how it came up with a negative 2ms duration. Seems > impossible to me, but I'll revisit that part of the code. At the very > least I won't allow such a result to be passed to the callbacks. By the way, there are plenty of negative timings on your Slickspeed and Taskspeed pages also... Also, using some of the special keys (menu key in particular) on your Keyboard page crashes Opera from time to time. :-( >> Key up at test4: 17 duration: 1 > > You are fast on the keys! :) Computers are much too slow for my fingers. :-) /Nisse
From: David Mark on 28 Jul 2010 15:04 On Jul 28, 8:41 am, Nisse Engström <news.NOSPAM.id...(a)luden.se> wrote: > On Mon, 26 Jul 2010 15:27:04 -0700 (PDT), David Mark wrote: > > On Jul 26, 1:24 pm, Nisse Engström <news.NOSPAM.id...(a)luden.se> wrote: > > >> Also, when Num Lock is off, "7" is intercepted > >> by Opera and produces: > > >> Key down at test4: 36 > >> Key down at test4: 0 > > > That's the "Home" key on the numeric keypad. On XP I get:- > > > Key down at test1: 36 > > Key up at test1: 36 duration: 131 > > > So something odd is going on there in Windows 98. > > Oops! I forgot that the "7" key on the numeric keypad is > flaky. It frequently activates the context menu, which I > believe is what happened here. Sorry about that. > Blame my caffein addiction. Lousy caffeine addiction! :) > > >> Most Alt-Gr combinations work fine, eg: > > (Note: That should have been "AltGr", eg. a single key.) > Sure Ctrl+Alt in one key. > > > > > >> Key down at test4: 18 > >> Key down at test4: 187 > >> -> Shortcut character at test4: "»" > > > Aha! There's a bug. I neglected to disallow "shortcut characters" > > when the altKey flag was set. Fixed! > > >> Character at test4: "\" (92) > >> Key up at test4: 187 duration: 97 > >> Key up at test4: 18 duration: 325 > > >> Key down at test4: 18 > >> Key down at test4: 194 > >> -> Shortcut character at test4: "â" > > > Same bug. Please try these two again. > > >> Character at test4: "|" (124) > >> Key up at test4: 194 duration: 107 > >> Key up at test4: 18 duration: 325 > > Key down at test2: 17 > Key down at test2: 18 > Key down at test2: 187 > Character at test2: "\" (92) > Key up at test2: 187 duration: 124 > Key up at test2: 18 duration: 324 > > Key down at test4: 18 > Key down at test4: 187 > Character at test4: "\" (92) > Key up at test4: 187 duration: 117 > Key up at test4: 18 duration: 350 > > Key down at test2: 17 > Key down at test2: 18 > Key down at test2: 194 > Character at test2: "|" (124) > Key up at test2: 194 duration: 97 > Key up at test2: 18 duration: 265 > > Key down at test4: 18 > Key down at test4: 194 > Character at test4: "|" (124) > Key up at test4: 194 duration: 50 > Key up at test4: 18 duration: 279 > > >> Escape: Only works once per page load. > > >> Key down at test4: 27 > > > In Opera, in a text input, that key causes the input to lose the > > focus. Canceling the keypress will prevent that and allow the keyup > > to come through. As with the arrow keys and PageUp/Down, it appears I > > need to add Esc to the list of keys handled by the onNavKeyPress > > callback. > > > Also, which sets of inputs are you testing? > > The now deprecated ones (because they were closer to the log). Yeah, sorry about the unfortunate layout of the test page. It was slapped together at the last minute (at great expense). :) > > > The other two inputs fire the keydown event for each press of the > > escape key (though never keyup as focus is lost immediately). That is > > the expected behavior. > > Confirmed. Cool. > > >> Modifiers keys: > >> --------------- > > > Again, I assume you are testing the second set of test inputs, which > > attempt to prevent duplicate control keydowns. You shouldn't have > > this problem on the first two. > > Ctrl AltGr AltGr Ctrl: > > [1st set] > > Key down at test2: 17 > Key up at test2: 17 duration: 112 Ctrl > > -> Key down at test2: 17 > Key down at test2: 18 AltGr > Key up at test2: 18 duration: 48 Yeah, that Ctrl+Alt combo key doesn't fire keyup for both (at least not in this browser). Odd choice for the browser developers (or maybe it is an oversight). > > -> Key down at test2: 17 > Key down at test2: 18 > Key up at test2: 18 duration: 101 AltGr > > Key down at test2: 17 > Key up at test2: 17 duration: 55 Ctrl Looks good. > > [2nd set] > > Key down at test4: 17 > Key up at test4: 17 duration: 109 > > -> Key down at test4: 17 > Key down at test4: 18 > Key up at test4: 18 duration: 94 > > Key down at test4: 18 > Key up at test4: 18 duration: 66 > > -> Key up at test4: 17 duration: 1869 The second set, which use a deprecated configuration option are not appropriate for all contexts (and this is one that will confuse it). > > Shift AltGr AltGr Shift: > > [1st set] > > Key down at test2: 16 > Key up at test2: 16 duration: 119 Shift > > -> Key down at test2: 17 > Key down at test2: 18 > Key up at test2: 18 duration: 108 AltGr > > -> Key down at test2: 17 > Key down at test2: 18 > Key up at test2: 18 duration: 89 AltGr > > Key down at test2: 16 > Key up at test2: 16 duration: 50 Shift Still batting 1.000. :) > > [2nd set] > > Key down at test4: 16 > Key up at test4: 16 duration: 50 > > Key down at test4: 18 > Key up at test4: 18 duration: 49 > > Key down at test4: 18 > Key up at test4: 18 duration: 174 > > Key down at test4: 16 > Key up at test4: 16 duration: 115 > > >> Cut/Copy/Paste: works fine and also generate key events. > >> Eg.: > > >> Key down at test4: 17 > >> Key down at test4: 86 > >> Shortcut character at test4: "V" > >> Key up at test4: 86 duration: -2 > > > I'm not sure how it came up with a negative 2ms duration. Seems > > impossible to me, but I'll revisit that part of the code. At the very > > least I won't allow such a result to be passed to the callbacks. > > By the way, there are plenty of negative timings on your > Slickspeed and Taskspeed pages also... I didn't write those test frameworks (just the test cases). ;) > > Also, using some of the special keys (menu key in particular) > on your Keyboard page crashes Opera from time to time. :-( I expect that is not specific to the test page, but a general bug in Opera related to pressing that key in an input. Is there a specific input common to the crashes. Most of them simply update the value of a text area. The other two update text inputs. Haven't seen any crashes myself (in any Opera versions). Which are you using again? > > >> Key up at test4: 17 duration: 1 > > > You are fast on the keys! :) > > Computers are much too slow for my fingers. :-) Yeah, mine too. Especially on the Web (usually due to dog-slow keyboard handling scripts).
From: David Mark on 28 Jul 2010 15:19 On Jul 28, 3:04 pm, David Mark <dmark.cins...(a)gmail.com> wrote: [...] > > I expect that is not specific to the test page, but a general bug in > Opera related to pressing that key in an input. Is there a specific > input common to the crashes. Most of them simply update the value of > a text area. The other two update text inputs. Haven't seen any > crashes myself (in any Opera versions). Which are you using again? > Thinking about this further, I suppose if Opera has a bug in its "special" key handling that is severe enough for it to crash (and assuming the crashes weren't related to some extraneous factor like a virus or trojan), I suppose that rapid-fire updating of the log (TEXTAREA) on all three key-related events could expose it. But that's just speculation. One thing is for sure: the attachKeyboardListeners function isn't doing anything flaky. It's a very simple callback mechanism with no voodoo. The tests and demos that call it are not doing anything odd either. If this is something you can reliably reproduce, I'd be glad to help pin down exactly what causes it. Might want to drop Opera a note as well. Also, the My Library add-on that I posted last night does not use DOM0 events, so comparing its test page (linked at the top of the source) to the original might shed some light (e.g. if it doesn't cause the issue to appear then Opera has a bug in its DOM0 event handling).
From: David Mark on 28 Jul 2010 17:40
On Jul 28, 3:19 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jul 28, 3:04 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > [...] > > > > > I expect that is not specific to the test page, but a general bug in > > Opera related to pressing that key in an input. Is there a specific > > input common to the crashes. Most of them simply update the value of > > a text area. The other two update text inputs. Haven't seen any > > crashes myself (in any Opera versions). Which are you using again? > > Thinking about this further, I suppose if Opera has a bug in its > "special" key handling that is severe enough for it to crash (and > assuming the crashes weren't related to some extraneous factor like a > virus or trojan), I suppose that rapid-fire updating of the log > (TEXTAREA) on all three key-related events could expose it. But > that's just speculation. One thing is for sure: the > attachKeyboardListeners function isn't doing anything flaky. It's a > very simple callback mechanism with no voodoo. The tests and demos > that call it are not doing anything odd either. > > If this is something you can reliably reproduce, I'd be glad to help > pin down exactly what causes it. Might want to drop Opera a note as > well. > > Also, the My Library add-on that I posted last night does not use DOM0 > events, so comparing its test page (linked at the top of the source) > to the original might shed some light (e.g. if it doesn't cause the > issue to appear then Opera has a bug in its DOM0 event handling). Also, is this on Win98? If so, Opera may well have stopped caring about that OS. Still, we can try to isolate it and send them a report. |