Keyboard test page updated
in [JavaScript]
|
From: David Mark on 26 Jul 2010 20:38 On Jul 26, 8:19 pm, SAM <stephanemoriaux.NoAd...(a)wanadoo.fr.invalid> wrote: > 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!
From: Adam Harvey on 27 Jul 2010 01:31 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. 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
From: David Mark on 27 Jul 2010 01:43 On Jul 26, 1:08 am, David Mark <dmark.cins...(a)gmail.com> wrote: > 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. :)
From: David Mark on 27 Jul 2010 01:52 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. > > 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!
From: David Mark on 27 Jul 2010 16:25
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... |