D
David Mark
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!
(Note: That should have been "AltGr", eg. a single key.)
Sure Ctrl+Alt in one key.
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
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.
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
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?
Computers are much too slow for my fingers.
Yeah, mine too. Especially on the Web (usually due to dog-slow
keyboard handling scripts).