Some key event handling issues of interest

As promised, here are some issues of interest that we had under  
consideration when reworking WebKit keyboard event handling.

- It is important to perform default handling of events at well- 
defined moments. E.g. having Tab perform its work of switching from  
one form control to other in keypress default  handler instead of  
keydown one was causing problems with sites filtering keystrokes (e.g.  
<http://bugs.webkit.org/show_bug.cgi?id=13916>).

- Default handlers are different for different elements. E.g. a space  
bar results in a space inserted from keypress default handler in an  
editable area; a button highlighted from keydown and a click event  
dispatched from keyup, a pop-up button menu displayed from keypress,  
or the page being scrolled down from a top-level keypress handler if  
the event bubbled without having been handled otherwise.

Sometimes, these differences are arbitrary (e.g. there is no technical  
reason for a pop-up button to necessarily display its menu from  
keypress, not keydown), but they are important for compatibility.

Clearly, this is mostly an issue with highly overloaded keys, such as  
Space, Enter, Tab, Backspace, or arrow keys.

- Interaction of DOM and browser chrome has to be considered. Keyboard  
shortcuts (such as Ctrl+F or Alt+F4 on Windows) are handled after DOM  
event dispatch, and some of them can be prevented, but not all.

Similarly, the browser chrome can perform an action that disrupts  
normal event flow. E.g., Ctrl+F moves focus to a search window, and  
thus a keydown event is not followed with a keyup one.

- Access keys are handled after keydown event dispatch, but they  
cannot be prevented. This behavior has been one of the most  
problematic parts for us because of a conflict with platform-supplied  
editing shortcuts on Mac OS X (such as Ctrl+A == move to beginning of  
line). I believe some other vendors have considered using another  
modifier combination for access keys (e.g. Ctrl+Shift), perhaps we  
should do the same.

- On Windows, the underlying platform provides two events for  
keystrokes (plus variations), one for physical key (WM_KEYDOWN ==  
keydown), and another for a character that it corresponds to (WM_CHAR  
== keypress). It is hard, or maybe even impossible, to second-guess  
which event comes when, because there are cases where they occur  
almost independently.

Here is an example, which I hope demonstrates the issue well, despite  
being an edge case from user point of view. On German keyboards, there  
is a dead key for circumflex (^), which modifies the results of the  
next keystroke. If it is pressed twice in succession, the sequence of  
events is: keydown, keyup, keydown, keypress, keypress, keyup. In  
other words, the first keystroke has no visible results, and "^^" is  
inserted on the second keystroke.

Mac OS X has a single event with both physical and processed key  
information. We have found it practical to emulate Windows behavior on  
the Mac, as there was no need to magically gather information from  
separate events.

So, we have removed physical key information (keyIdentifier,  
keyLocation) from keypress events. For compatibility, they still have  
keyCode, but it is equal to charCode. Since keypress has not been  
previously defined in DOM3 Events, either behavior is compliant :)

- Preventing default handling of keydown has no effect on IME input;  
keypress is not dispatched. Also, keyCode is set to 229  
(VK_PROCESSKEY) in the keydown event. This was done just to provide IE  
compatibility, I do not have any other support for this rather counter- 
intuitive behavior.

- WBR, Alexey Proskuryakov

Received on Thursday, 3 April 2008 09:14:41 UTC