Tested in Opera 10.54/Windows 98SE using an
IBM KB-9930 keyboard.
Letters and numbers
-------------------
Seem to work as expected, eg:
Key down at test4: 65
Character at test4: "a" (97)
Key up at test4: 65 duration: 104
Key down at test4: 16
Key down at test4: 65
Character at test4: "A" (65)
Key up at test4: 65 duration: 114
Key up at test4: 16 duration: 395
Key down at test4: 16
Key down at test4: 65
Character at test4: "A" (65)
Key up at test4: 65 duration: 112
Key down at test4: 66
Character at test4: "B" (66)
Key up at test4: 66 duration: 112
Key up at test4: 16 duration: 990
The Swedish letters (åäöÅÄÖ) are also fine.
Punctuation
-----------
Most single-key and shifted keys work fine (similar to the above).
There are some exceptions on the numerical keypad:
Key down at test4: 47
Character at test4: "/" (47)
Character at test4: "/" (47)
Key up at test4: 47 duration: 64
Key down at test4: 42
Character at test4: "*" (42)
Character at test4: "*" (42)
Key up at test4: 42 duration: 53
Key down at test4: 45
Key up at test4: 45 duration: 50
Key down at test4: 43
Character at test4: "+" (43)
Character at test4: "+" (43)
Key up at test4: 43 duration: 115
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.
Most Alt-Gr combinations work fine, eg:
That's Ctrl+Alt (on non-US keyboards) for you following at home.
Key down at test4: 18
Key down at test4: 50
Shortcut character at test4: "2"
That's not right. The "short character" feature is only supposed to
work with Ctrl (or CMD on Mac). I don't see that here. Of course Ctrl
+2 gets intercepted by Opera on my end. I should probably add another
set of test inputs that cancel the default behavior for all key
presses.
Character at test4: "@" (64)
Key up at test4: 50 duration: 113
Key up at test4: 18 duration: 271
Some observations:
Testing backslash ("+?\" key).
Key down at test4: 18
That's the alt key here.
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!
The "shortcut character" feature is a bit of a silly afterthought. I
was working on something for a client where they wanted to detect
things like Ctrl+V, Ctrl+X, etc. (paste and cut in Windows). I will
likely remove that callback when I can this as an add-on for My
Library.
Character at test4: "\" (92)
Key up at test4: 187 duration: 97
Key up at test4: 18 duration: 325
Testing pipe ("<>|" key).
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
Are those working as expected? Are the indicated
lines side effects of the characters not being
fully composed?
Definitely not what I would have expected, but then I didn't have an
AltGr key.
JFTR, when I do "<>\", I have to shift the first two, but not the last
and get the expected result:-
Key down at test1: 16
Key down at test1: 188
Character at test1: "<" (60)
Key up at test1: 188 duration: 120
Key down at test1: 190
Character at test1: ">" (62)
Key up at test1: 190 duration: 97
Key up at test1: 16 duration: 933
Key down at test1: 220
Character at test1: "\" (92)
Key up at test1: 220 duration: 68
As for "+?\", shift is again needed for the first two, but not the
last and the results are as expected:-
Key down at test1: 16
Key down at test1: 61
Character at test1: "+" (43)
Key up at test1: 61 duration: 2
Key down at test1: 191
Character at test1: "?" (63)
Key up at test1: 191 duration: 98
Key up at test1: 16 duration: 406
Key down at test1: 220
Character at test1: "\" (92)
Key up at test1: 220 duration: 81
The AltGr key strikes again.
I saw the following happen a couple of times, but cannot
reproduce it anymore:
"^" (Shift-"¨^~"):
Key down at test4: 16
Key down at test4: 186
Key up at test4: 186 duration: 100
Key up at test4: 16 duration: 490
Key down at test4: 32
Character at test4: "^" (94)
Key up at test4: 32 duration: 50
-> Key down at test4: 18
followed by "~" (AltGr-"¨^~"):
Key down at test4: 186
Shortcut character at test4: "º"
Key up at test4: 186 duration: 86
-> Key up at test4: 18 duration: 47275
That will happen if key up events get "eaten" by the browser (usually
when a combination of Ctrl, Alt, AltGr or whatever triggers a browser
shortcut). This is why it is important to cancel the default action
of "shortcut" key presses in production code.
Key down at test4: 32
Character at test4: "~" (126)
Key up at test4: 32 duration: 120
Function keys:
--------------
Only keydown event (because of focus shift):
F1, F2, F3, F7, F8
Expected.
Keydown and Keyup event:
F4, F6, F9, F10, F12
Good.
Nothing:
F5 (Reload)
I get the keydown only as the page is reloaded before keyup fires.
Canceling the keypress would allow both to appear.
And F11 resulted in:
Key down at test4: 122
Key down at test4: 376
Key up at test4: 122 duration: 11823
Key up at test4: 376 duration: 11750
Interesting. I get:-
Key down at test1: 122
Key up at test1: 122 duration: 2252
(and the browser goes into full-screen mode).
Most or all function keys are also intercepted by Opera.
Yes, those are definitely not something to rely on in production code.
Special keys:
-------------
Windows key: Only works once per page load.
Key down at test4: 219
That one will be flaky due to the browser window being deactivated in
favor of the start menu. JFTR, I get:-
Key down at test1: 219
Key up at test1: 219 duration: 84
Key down at test3: 219
Key up at test3: 219 duration: 121
Key down at test3: 219
Key up at test3: 219 duration: 121
Key down at test1: 219
Key up at test1: 219 duration: 82
....in both sets of inputs, though occasionally see the expected
dropped keyup.
Menu key:
Key down at test4: 0
or
Key down at test4: 0
Key up at test4: 0 duration: 5209
I just tried it and got the latter.
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?
I see the missing keydown causing the "one time only" problem only in
the sets where auto-repeat of control characters is disabled. That
option (last argument) is not recommended and will likely be removed
now that the OS auto-repeat is supported. It was there to allow
applications to handle auto-repeat their own way because I didn't have
a cross-browser solution for that on the first take. I suppose I
could still support it reliably (if there is any call) by adding a
blur listener to reset the flags that track held keys. Seems like a
waste of time though.
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.
Shift-Escape: (also intercepted by Opera)
Key down at test4: 16
Key down at test4: 27
Key up at test4: 27 duration: 104
Key up at test4: 16 duration: 487
Good.
Tab:
Key down at test4: 9
After which the field loses focus. By coincidence (because I am
tabbing from one monitored field to the next), I get this:-
Key down at test1: 9
Key up at test2: 9 duration: 81
...and this in the other set:-
Key down at test3: 9
Key up at test4: 9 duration: 81
And then Shift-Tab:
Key up at test4: 9 duration: 53
Key up at test4: 16 duration: 425
Yes, because test3 lost the focus (and the keyup event) before. BTW,
test3 and 4 are the "bad" contols (configued to disallow control keys
from auto-repeating).
Caps Lock/Pause: Work fine.
Print Screen: Nothing.
Same here. Not unexpected as the OS (or browser) likely intercepts
that one.
Scroll Lock:
Key down at test4: 145
Character at test4: "‘" (145)
That's a bug in Opera and I don't think there is any way around it.
Suffice to say that the Scroll Lock (like many of these examples) is
not a good key to rely on.
Key up at test4: 145 duration: 57
Num Lock:
Key down at test4: 144
Character at test4: " " (144)
Same bug in Opera.
Key down at test4: 376
Key up at test4: 376 duration: 106
Key up at test4: 144 duration: 111
Interesting. I get:-
Key down at test1: 144
Character at test1: "" (144)
Key up at test1: 144 duration: 13
....and am not sure why you are getting a 376 in the mix.
Ins/Home/End/Page Up/Page Down: Keyup and Keydown.
Del:
Key down at test4: 46
Key down at test4: 376
Key up at test4: 46 duration: 117
Key up at test4: 376 duration: 66
376 again? I'll have to Google that one.
Backspace:
Key down at test4: 8
Character at test4: " " (8)
Key up at test4: 8 duration: 60
Good.
Enter:
Key down at test4: 13
Character at test4: "
" (13)
Key up at test4: 13 duration: 64
Good.
Arrow Left/Right/Up: Keyup and keydown.
Arrow Down:
Key down at test4: 40
Key down at test4: 376
Key up at test4: 40 duration: 68
Key up at test4: 376 duration: 67
376 otra vez.

376 is some sort of (non-US) phantom it seems.
Prev/Next keys (on either side of the "Arrow Up" key;
Few keyboards have them) are fully intercepted by Opera.
As to be expected as the test fields do not cancel any default
actions. The demos below them do and the arrows should work find
there.
Modifiers keys:
---------------
AltGr key, first time after page load or clearing log:
Key down at test4: 17
Key down at test4: 18
Key up at test4: 18 duration: 107
That's certainly odd.
AltGr key again:
Key down at test4: 18
Key up at test4: 18 duration: 72
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.
Then Ctrl key:
Key up at test4: 17 duration: 3073
As expected due to the previous mistake (it thinks you were holding
down control the whole time).
Ctrl key again:
Key down at test4: 17
Key up at test4: 17 duration: 50
Good.
AltGr again:
Key down at test4: 17
Key down at test4: 18
Key up at test4: 18 duration: 47
Something is odd with Opera's reporting of AltGr it seems.
----------
Extra keys
----------
Extra keys (IBM Support/Standby/CD operation and similar)
also generate Keydown and Keyup events.
Good.
----
Misc
----
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.
Key up at test4: 17 duration: 1
You are fast on the keys!
Very little it seems. Thanks very much for the in-depth effort. Much
of the inconsistencies logged were to be expected due to the fact that
the test callbacks do not cancel any default actions. This was by
design as I wanted to see every possible problem. For instance, I had
already seen the viewport scrolling in response to the up/down arrow
keys in Opera (and in fact, an auto-fill menu in its default
configuration for text inputs). These issues were remedied by
canceling the default actions (returning false from the onNavKeyPress
callback).
In the second set of inputs, the loss of focus (and keyup events)
created by the various browser and OS accelerator keys (e.g. F11) and
combinations cascaded to expose a shortcoming in the (soon to be
deprecated) feature that tries to suppress duplicate control key
downs.
Thanks again, Nisse! Glad things are (mostly) working on the Swedish
front.
Now I'd really like to hear from users of Asian language keyboards...