Keyboard test page updated

D

David Mark

I'd like some feedback on this. I'm more interested in the
functionality than code critiques at the moment (though either is
welcome).

Keyboard handling is one of the hardest cross-browser issues. I don't
claim this is perfect, but it smooths over various issues I've
encountered over the years when dealing with keyboard input. The most
important one for me is that auto-repeated arrow keys produce
consistent results. The way I dealt with this issue in the original
take was to optionally suppress the repeated keydown events and leave
it up to the application to use an interval (waiting for the matching
keyup to stop repeating). In this latest version I have removed that
burden.

I recently added some "real world" examples: a number spinner (without
extraneous buttons as it is only to test keyboard control) and a
character counter.

http://www.cinsoft.net/keyboard.html

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. :)
 
D

David Mark

Backspace:

Key down at test1: 8
Character at test1: " " (8)
Key up at test1: 8 duration: 127

Delete:

Key down at test1: 46
Key up at test1: 46 duration: 192

Insert:

Key down at test1: 45
Key up at test1: 45 duration: 120

Looks good. What OS are you using?
For these (what I call) named keys I wonder if it would be a good idea
if a name was returned e.g. Backspace, Delete, Insert... Though I guess
that would stuff internationalisation.

Yeah, that would be a rub.
---

PrtScr always only gives (no key down):

Key up at test1: 44 duration: undefined

I get nothing at all in Opera. The browser intercepts it apparently
(which is not unexpected for that key).
---

Enter:

Character at test1: "
" (13)

Will it cause issues with it split over 2 lines?

The logging is simply for debugging on the test page. The function
itself does not return such strings.

Thanks!
 
S

SAM

Le 7/26/10 12:00 PM, Andrew Poulos a écrit :
Backspace:

Key down at test1: 8
Character at test1: "" (8)
Key up at test1: 8 duration: 127

Delete:

Key down at test1: 46
Key up at test1: 46 duration: 192

Insert:

Key down at test1: 45
Key up at test1: 45 duration: 120

On my Mac :

(that key is for 'Help')
Key up at test4: 45 duration: undefined

For these (what I call) named keys I wonder if it would be a good idea
if a name was returned e.g. Backspace, Delete, Insert... Though I guess
that would stuff internationalisation.

and what about arrows keys ?

Key down at test4: 40
Key up at test4: 40 duration: 16
Key down at test4: 39
Key up at test4: 39 duration: 144
Key down at test4: 37
Key up at test4: 37 duration: 128
Key down at test4: 38
Key up at test4: 38 duration: 120

or page-up/down or document-up/down ?

Key down at test4: 36
Key up at test4: 36 duration: 136
Key down at test4: 35
Key up at test4: 35 duration: 143
Key down at test4: 33
Key up at test4: 33 duration: 135
Key down at test4: 34
Key up at test4: 34 duration: 120
---

PrtScr always only gives (no key down):

Key up at test1: 44 duration: undefined

No "PrtScr" on Mac --> I'ven't found that number 44
---

Enter:

Character at test1: "
" (13)

Will it cause issues with it split over 2 lines?

Andrew Poulos

other "named keys" ...
Ctrl, Option, Apple :

Key down at test4: 17
Key up at test4: 17 duration: 176
Key down at test4: 18
Key up at test4: 18 duration: 112
Key down at test4: 224
Key up at test4: 224 duration: 104

Key [$*¥€] :

Key down at test4: 0
Character at test4: "$" (36)
Key up at test4: 0 duration: 152

Key [@£`]:

Key down at test4: 0
Key up at test4: 0 duration: 168

Key [@#] :

Key down at test4: 0
Character at test4: "@" (64)

Key down at test4: 16
Key down at test4: 0
Character at test4: "#" (35)
Key up at test4: 0 duration: 217
Key up at test4: 16 duration: 1680
 
N

Nisse Engström

I'd like some feedback on this. I'm more interested in the
functionality than code critiques at the moment (though either is
welcome).

http://www.cinsoft.net/keyboard.html

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

Most Alt-Gr combinations work fine, eg:

Key down at test4: 18
Key down at test4: 50
Shortcut character at test4: "2"
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
Key down at test4: 187
-> Shortcut character at test4: "»"
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: "â"
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?


Composing keys
--------------

Composing keys work fine, except sometimes where
"AltGr" is involved. (See also Modifier keys below).

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
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

Keydown and Keyup event:

F4, F6, F9, F10, F12

Nothing:

F5 (Reload)

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

Most or all function keys are also intercepted by Opera.


Special keys:
-------------

Windows key: Only works once per page load.

Key down at test4: 219

Menu key:

Key down at test4: 0

or

Key down at test4: 0
Key up at test4: 0 duration: 5209

Escape: Only works once per page load.

Key down at test4: 27

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

Tab:

Key down at test4: 9

And then Shift-Tab:

Key up at test4: 9 duration: 53
Key up at test4: 16 duration: 425

Caps Lock/Pause: Work fine.

Print Screen: Nothing.

Scroll Lock:

Key down at test4: 145
Character at test4: "‘" (145)
Key up at test4: 145 duration: 57

Num Lock:

Key down at test4: 144
Character at test4: "Â" (144)
Key down at test4: 376
Key up at test4: 376 duration: 106
Key up at test4: 144 duration: 111

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

Backspace:

Key down at test4: 8
Character at test4: "" (8)
Key up at test4: 8 duration: 60

Enter:

Key down at test4: 13
Character at test4: "
" (13)
Key up at test4: 13 duration: 64

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

Prev/Next keys (on either side of the "Arrow Up" key;
Few keyboards have them) are fully intercepted by Opera.




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

AltGr key again:

Key down at test4: 18
Key up at test4: 18 duration: 72

Then Ctrl key:

Key up at test4: 17 duration: 3073

Ctrl key again:

Key down at test4: 17
Key up at test4: 17 duration: 50

AltGr again:

Key down at test4: 17
Key down at test4: 18
Key up at test4: 18 duration: 47


----------
Extra keys
----------

Extra keys (IBM Support/Standby/CD operation and similar)
also generate Keydown and Keyup events.


----
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
Key up at test4: 17 duration: 1



What did I forget?


/Nisse
 
D

David Mark

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
Composing keys

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! :)
What did I forget?

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...
 
D

David Mark

[...]
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.

All set. See updated document. Just goes to show that even the worst
of the worst sorts of cross-browser demons can be exorcised with
documentation and deprecation. ;)
 
D

David Mark

Le 7/26/10 12:00 PM, Andrew Poulos a écrit :






On my Mac :

(that key is for 'Help')
Key up at test4: 45 duration: undefined


and what about arrows keys ?

Key down at test4: 40
Key up at test4: 40 duration: 16
Key down at test4: 39
Key up at test4: 39 duration: 144
Key down at test4: 37
Key up at test4: 37 duration: 128
Key down at test4: 38
Key up at test4: 38 duration: 120

or page-up/down or document-up/down ?

Key down at test4: 36
Key up at test4: 36 duration: 136
Key down at test4: 35
Key up at test4: 35 duration: 143
Key down at test4: 33
Key up at test4: 33 duration: 135
Key down at test4: 34
Key up at test4: 34 duration: 120




No "PrtScr" on Mac --> I'ven't found that number 44




other "named keys" ...
Ctrl, Option, Apple :

Key down at test4: 17
Key up at test4: 17 duration: 176
Key down at test4: 18
Key up at test4: 18 duration: 112
Key down at test4: 224
Key up at test4: 224 duration: 104

All look good.
Key [$*¥€] :

Key down at test4: 0
Character at test4: "$" (36)
Key up at test4: 0 duration: 152

That doesn't. :( You typed a total of four characters, right?
Key [@£`]:

Key down at test4: 0
Key up at test4: 0 duration: 168

What is wrong with your keyboard? :)
Key [@#] :

Key down at test4: 0
Character at test4: "@" (64)

Key down at test4: 16
Key down at test4: 0
Character at test4: "#" (35)
Key up at test4: 0 duration: 217
Key up at test4: 16 duration: 1680

What browser/OS? Mac if I recall?

Thanks a lot for your help, SAM!
 
S

SAM

Le 7/27/10 12:43 AM, David Mark a écrit :

<http://www.cinsoft.net/keyboard.html>

I don't know what could be a "Control Keys Auto-repeat"

The "log" is to far down, can't we get it on right side ?
(column tests and demos - column for logs)

I'll not test functions keys as they are reserved for the system and for
applications.
All look good.

it seems to me that there are "special" keys detections for those keys


alpha Enter key = num Enter key = 13

Control and Alt keys : right and left are the same
(as Command/Apple key)
Key [$*¥€] :

Key down at test4: 0
Character at test4: "$" (36)
Key up at test4: 0 duration: 152

That doesn't. :( You typed a total of four characters, right?

On Apple AZERTY French keyboard for France with num pad
(Canada, Belgium, Swiss, I don't know)
See png here :
<http://cjoint.com/data/hBcqmsGpzg_french-fr-apple-keyboard_.png>

It's a key with alternatively 4 characters
normal press : $
Alt(or Option) + $ = €
Shift + $ = *
Alt + Shift + $ = ¥

Key [@£`]:

Key down at test4: 0
Key up at test4: 0 duration: 168

What is wrong with your keyboard? :)

Mystère et boule de gomme ;-)

key : `
Shift + ` = £
Shift + Alt + ` = #

Key @ (on left side of numbers keys on alpha keyboard part)

Shift + @ = #
What browser/OS? Mac if I recall?

Firefox.3 on French Mac (system 10.4.11)
Thanks a lot for your help, SAM!

Test 4 :
<http://cjoint.com/?hBclIG2m7M>
<http://cjoint.com/data/hBclIG2m7M_french-fr-apple-keyboard-test2.htm>
 
D

David Mark

Le 7/27/10 12:43 AM, David Mark a écrit :

<http://www.cinsoft.net/keyboard.html>

I don't know what could be a "Control Keys Auto-repeat"

Duplicate onkey callbacks are allowed for keys that do not correspond
to characters (e.g. arrow keys). These happen in either the keydown
or keypress events, depending on the browser. This was the hardest
bit to get right cross-browser (and something that the libraries
incessantly sniff for).

If you set the last argument to the function to true, it tries to
prevent duplicates (sometimes with less than desirable results,
depending on what the callbacks do).
The "log" is to far down, can't we get it on right side ?

I agree. After I added the demos between the test inputs and the log,
I should have moved the log up. Will change when I have a chance.
(column tests and demos - column for logs)

I'll not test functions keys as they are reserved for the system and for
applications.

Yeah, it's ill-advised to design interface that listen for function
keys, scroll lock, print screen, window key, Apple key, etc.

I appreciate the help!
 
A

Adam Harvey

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.


First, Chrome 6.0.472.0 dev (the current development release):

All additional keys (Stop, Again, Copy, Paste, et cetera) return key code
0:

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

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.)
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)
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

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

Control-X is identical:

Key down at test1: 17
Key down at test1: 88
Shortcut character at test1: "X"
Key up at test1: 88 duration: 29
Key up at test1: 17 duration: 92

Using compose to generate é doesn't add a "character at" log entry,
interestingly:

Key up at test1: 0 duration: undefined
Key up at test1: 222 duration: undefined
Key up at test1: 69 duration: undefined


Adam

[0] http://en.wikipedia.org/wiki/Compose_key
 
D

David Mark

I'd like some feedback on this.  I'm more interested in the
functionality than code critiques at the moment (though either is
welcome).

Keyboard handling is one of the hardest cross-browser issues.  I don't
claim this is perfect, but it smooths over various issues I've
encountered over the years when dealing with keyboard input.  The most
important one for me is that auto-repeated arrow keys produce
consistent results.  The way I dealt with this issue in the original
take was to optionally suppress the repeated keydown events and leave
it up to the application to use an interval (waiting for the matching
keyup to stop repeating).  In this latest version I have removed that
burden.

I recently added some "real world" examples: a number spinner (without
extraneous buttons as it is only to test keyboard control) and a
character counter.

http://www.cinsoft.net/keyboard.html

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.  :)

Porting this over to an add-on for My Library (which involved changing
about five lines of code), I do see one little fly in the ointment
with regard to what I've (somewhat awkwardly) called "shortcut
characters" (in this implementation, alphanumerics combined with the
Control or Meta keys). These are known (more appropriately) as
"accelerators" in desktop software development and serve as keyboard
"shortcuts" to commands (i.e. no need to move off the keyboard to
maneuver the mouse to the toolbar or go through the rigors of
traversing menus).

If widgets (ill-advisedly) wish to respond to combinations like Ctrl+C
(Meta+C on Mac), Ctrl+3, etc., there must be a reliable way to cancel
the default behavior.

Canceling the default in the onkey callback when the event type is
keydown will only work if the widget is to act upon the combination at
that time (as IIRC in some browsers canceling the keydown event will
short-circuit keypress and/or keyup).

I find acting upon keydown as if it were a keypress to be extremely
bad form (though such practice is prevalent). After all, a physical
key press does not occur until after the key is released. Of course,
some screwed-up browsers (e.g. Opera) use only keypress events to
signal auto-repeated control keys, but that's another story.

Taken to a ridiculous extreme, some libraries (e.g. Dojo) fire faux
keypress events on keydown after sniffing out certain browsers (e.g.
IE) that they assume will not generate keypress events for the (for
example) backspace and enter keys on their own. Obviously that
"solution" is in the same poor taste as the application would be
responding to a "keypress" before the user has finished pressing the
key.

Anyway, looking at my code, it appears that some browsers do not fire
keypress events for "shortcuts" (only keydown and keyup for each key
in the combination). I dealt with this (as I dealt with other similar
issues) by monitoring the behavior and calling the onshortcutchar
callback on keyup when needed (followed immediately by the appropriate
call to onkeyup). What stuck out was that there was no attempt to
deal with a false value returned from the onshortcutchar callback
(unlike in similar code found in the keypress listener). I'm sure I
(rightly as it turns out) assumed that canceling the keyup event would
be pointless.

After playing around a bit, it appears there is no consistent cross-
browser way to prevent accelerators like Ctrl+P from doing their
business (for any script). All that is left is to try to guess which
are universally available (i.e. not reserved by any browser, at least
for operations that cause the document to lose focus), which is
certainly impossible. All of those widgets out there that rely on Ctrl
+Shift+Q or whatever are simply being foolhardy.

What's the reasonable answer for widget developers? Stick to the
arrow keys, escape, PageDown, PageUp, etc. There are certainly enough
combinations when combined with control and shift. Depending on the
context, the accessKey property can be used as well, but IIRC, IE
stupidly allows that to conflict with menu mnemonics (e.g. F is for
File and IE uses Alt to trigger access keys).

Also, I spotted the bit of illogic that was causing the one issue
noted on the test page (failure of IE to auto-repeat backspace/
enter). Looks like an old remnant that no longer belonged (the code
has gotten a bit messy since the first take). I'll re-test thoroughly
tomorrow and post a new version. Will post the My Library version
shortly thereafter. Will also move the log above the demos for easier
viewing as well (sorry about that).

Thanks to all those who have helped. Still waiting to hear from Asia
BTW...

And speaking of waiting, still no congratulatory note from that
Cappuccino guy. Must be lost in the mail. Or maybe he's too busy
taking notes. :)
 
D

David Mark

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.
Control-X is identical:

Key down at test1: 17
Key down at test1: 88
Shortcut character at test1: "X"
Key up at test1: 88 duration: 29
Key up at test1: 17 duration: 92

Good deal.
Using compose to generate é doesn't add a "character at" log entry,
interestingly:

Key up at test1: 0 duration: undefined
Key up at test1: 222 duration: undefined
Key up at test1: 69 duration: undefined

D'oh! Lousy compose key! :) All I can figure is that is a bug in
FF. I'll report it when I have a chance.

Thanks Adam!
 
D

David Mark

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...
 
D

David Mark

I'd really prefer to stick to general release versions, but no
matter.  :)
Yes, I think we saw a bit of this in previous follow-ups.  Clearly
those are useless for browser scripting.
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.
Well, at least the character came through unscathed.  :)
Good to be consistent.
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.
 
D

David Mark

Le 7/27/10 12:43 AM, David Mark a écrit :

<http://www.cinsoft.net/keyboard.html>

I don't know what could be a "Control Keys Auto-repeat"

The "log" is to far down, can't we get it on right side ?
(column tests and demos - column for logs)

I'll not test functions keys as they are reserved for the system and for
applications.
All look good.

it seems to me that there are "special" keys detections for those keys

alpha Enter key = num Enter key = 13

Control and Alt keys : right and left are the same
(as Command/Apple key)
Key [$*¥€] :
Key down at test4: 0
Character at test4: "$" (36)
Key up at test4: 0 duration: 152
That doesn't.  :(  You typed a total of four characters, right?

On Apple AZERTY French keyboard for France with num pad
(Canada, Belgium, Swiss, I don't know)
See png here :
<http://cjoint.com/data/hBcqmsGpzg_french-fr-apple-keyboard_.png>

It's a key with alternatively 4 characters
        normal press : $
        Alt(or Option) + $ = €
        Shift + $ = *
        Alt + Shift + $ = ¥

Ah, that explains it.
Key [@£`]:
Key down at test4: 0
Key up at test4: 0 duration: 168
What is wrong with your keyboard?  :)

Mystère et boule de gomme ;-)

key : `
Shift + ` = £
Shift + Alt + ` = #

Key @ (on left side of numbers keys on alpha keyboard part)

Shift + @ = #
What browser/OS?  Mac if I recall?

Firefox.3 on French Mac (system 10.4.11)
Thanks a lot for your help, SAM!

Test 4 :
<http://cjoint.com/?hBclIG2m7M>
<http://cjoint.com/data/hBclIG2m7M_french-fr-apple-keyboard-test2.htm>

Wow. Thanks a lot! Will dig through those in a moment. :)
 
D

David Mark

Le 7/27/10 12:43 AM, David Mark a écrit :

<http://www.cinsoft.net/keyboard.html>

I don't know what could be a "Control Keys Auto-repeat"

The "log" is to far down, can't we get it on right side ?
(column tests and demos - column for logs)

I'll not test functions keys as they are reserved for the system and for
applications.
All look good.

it seems to me that there are "special" keys detections for those keys

alpha Enter key = num Enter key = 13

Control and Alt keys : right and left are the same
(as Command/Apple key)
Key [$*¥€] :
Key down at test4: 0
Character at test4: "$" (36)
Key up at test4: 0 duration: 152
That doesn't.  :(  You typed a total of four characters, right?

On Apple AZERTY French keyboard for France with num pad
(Canada, Belgium, Swiss, I don't know)
See png here :
<http://cjoint.com/data/hBcqmsGpzg_french-fr-apple-keyboard_.png>

It's a key with alternatively 4 characters
        normal press : $
        Alt(or Option) + $ = €
        Shift + $ = *
        Alt + Shift + $ = ¥
Key [@£`]:
Key down at test4: 0
Key up at test4: 0 duration: 168
What is wrong with your keyboard?  :)

Mystère et boule de gomme ;-)

key : `
Shift + ` = £
Shift + Alt + ` = #

Key @ (on left side of numbers keys on alpha keyboard part)

Shift + @ = #
What browser/OS?  Mac if I recall?

Firefox.3 on French Mac (system 10.4.11)
Thanks a lot for your help, SAM!

Test 4 :
<http://cjoint.com/?hBclIG2m7M>
<http://cjoint.com/data/hBclIG2m7M_french-fr-apple-keyboard-test2.htm>

At a glance, they look good. You have those odd (0) keydown/keyup's
on some of the more esoteric characters (esoteric for me I mean, they
may well be common in French). But the characters are what's
important and appear to be getting through unscathed.

Thanks again!
 
S

SAM

Le 7/27/10 11:07 PM, David Mark a écrit :(...)
Test on Mac (French France keyboard)that file will autodestroy itself in few days (3 weeks)
At a glance, they look good. You have those odd (0) keydown/keyup's
on some of the more esoteric characters (esoteric for me I mean, they
may well be common in French).

Keys (keyCode==0) : @ $ ù ` <
or associated with Shift maintained (pressed) : # * ¨ £ >

Key @ : keyCode --> 0 charCode --> 64 character --> @
But the characters are what's
important and appear to be getting through unscathed.

Indeed, if not ... how to get them from a keyboard to another one ?

Meta (Apple) : 224 (left & right) evt.metaKey --> true
Control : 17 (left & right) evt.ctrlKey --> true
Alt (Option) : 18 (left & right) evt.altKey --> true
Shift : 16 (left & right) evt.shiftKey --> true

evt.keyCode
Tab : 9
Enter : 13 (alpha & num)
Backspace : 8
Arrows :
left : 37
up : 38
right : 39
down : 40

F1 : 112 and increasing up to F8
F9 to F12 and F14 to F16 : no keyCode (reserved for system)
F13 : 44
 
D

David Mark

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 onlyhave 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 Iam
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, hereare
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 oneI
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.

Won't be a problem in the add-on version as, to keep with the general
style of higher-level My Library code, I consolidated all of the
arguments (save for the element reference) into one options object.

Testing a modified test page for the add-on now. Should update the
Downloads page shortly. This add-on will make writing things like UI
widgets and games very easy. As seen on the recently posted Touch
demo, a minimal build (< 25K) can go a long way. Combined with the
Transform add-on, I think My Library is the only suitable candidate
for mobile development.

And speaking of mobiles devices, next up is the Page Transition add-
on, which I recently used to retrofit my entire site to fit and slide
like a native on newer handhelds. Will post that stuff in the next
few days... This is exciting, isn't it? :)
 
D

David Mark

On Sun, 25 Jul 2010 22:08:43 -0700, David Mark wrote:
Looks good to me at this point, having tested numerous browsersreleased
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 pointI am
open to observations and the inevitable workarounds.  But I'msure 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 downright
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 shockme
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...

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. :)
 
N

Nisse Engström

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.

(Note: That should have been "AltGr", eg. a single key.)
Aha! There's a bug. I neglected to disallow "shortcut characters"
when the altKey flag was set. Fixed!


Same bug. Please try these two again.

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
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.


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
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. :-(
You are fast on the keys! :)

Computers are much too slow for my fingers. :)


/Nisse
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,757
Messages
2,569,543
Members
45,026
Latest member
camilin05

Latest Threads

Top