I scanned the above answers and the proposed keydown
/keyup
approach works only under special circumstances. If the user alt-tabs away, or uses a key gesture to open a new browser window or tab, then a keydown
will be registered, which is fine, because at that point it's impossible to tell if the key is something the web app is monitoring, or is a standard browser or OS shortcut. Coming back to the browser page, it'll still think the key is held, though it was released in the meantime. Or some key is simply kept held, while the user is switching to another tab or application with the mouse, then released outside our page.
Modifier keys (Shift
etc.) can be monitored via mousemove
etc. assuming that there is at least one mouse interaction expected when tabbing back, which is frequently the case.
For most all other keys (except modifiers, Tab
, Delete
, but including Space
, Enter
), monitoring keypress
would work for most applications - a key held down will continue to fire. There's some latency in resetting the key though, due to the periodicity of keypress
firing. Basically, if keypress
doesn't keep firing, then it's possible to rule out most of the keys. This, combined with the modifiers is pretty airtight, though I haven't explored what to do with Tab
and Backspace
.
I'm sure there's some library out there that abstracts over this DOM weakness, or maybe some DOM standard change took care of it, since it's a rather old question.