I've been noticing some interesting behavior with my iPad+Bluetooth Keyboard in vBulletin's WYSISYG editor. When I have caps lock on, the B, U, and I keys create vBulletin bold, underline, and italic tags, respectively. They insert both the opening and closing tag, and leave the cursor in the middle. Holding down shift and typing the same letter obviously doesn't do the same, and the vBulletin editor doesn't respond to any Ctrl or ⌘ key combinations. I can't get the on-screen keyboard to emulate the behavior either, even with double-tap caps lock on.
That got me curious about what effect Caps Lock has on Mobile Safari's keypress events, so I did some experimenting. What I found was a rabbit's warren of browser-specific implementation discrepancies as to how keypress events are constructed by different browsers. I originally tracked all three keyboard events (keydown, keypress, keyup), but got so confused that I turned off the keydown and keyup handlers to focus on keypress.
Interesting findings:
On the iPad, when caps lock is active on the external keyboard, pressing a key sends all three events (as it should). But while keydown and keypress have metaKey=true and ctrlKey=true, actually holding down Ctrl and/or ⌘ (with caps lock off) has no similar effect. Furthermore, the keyup event has metaKey=false and ctrlKey=false.
Every browser I tried has its own way of populating the keypress event object when handling Ctrl+⌘+I:
| browser | which | shiftKey | metaKey | keyCode | ctrlKey | charCode | altKey |
|---|---|---|---|---|---|---|---|
| Firefox 3.6.8 | 105 | false | true | 0 | true | 105 | false |
| Desktop Safari 5.0.1 | 9 | false | true | 9 | true | 9 | false |
| Mobile Safari 4.0.4 | 73 | false | true | 73 | true | 73 | false |
(Common and undefined attributes removed for clarity.)
Mobile Safari puts the value 73 (ASCII uppercase I) in which, keyCode, and charCode, while Desktop Safari populates those properties with 9 (ASCII TAB, usually bound to Ctrl+I on most keyboards). Firefox, meanwhile, only populates which and charCode (with 105, or ASCII lowercase i), leaving keyCode at 0. Granted, I'm using different major versions of Safari on the desktop vs. the iPad, but it's still an interesting discrepancy.