![]() |
Key Events in SeaMonkeylast modified:9/28/1999 Tague and Kathy's proposal 9/19/99 Results of second meeting Steve Clark (buster@netscape.com) 9/15/99 Initial draft Steve Clark (buster@netscape.com) 1. IntroductionThis document is a specification for all aspects of key events in SeaMonkey applications. It describes key event generation, propogation, and processing. It is particularly important for platform developers to understand the key event generation section.2. Key Event GenerationNative input methods (used when typing Japanese), aka IME, must have first crack at all keyboard events this includes accelerators and keybindings because they might be used by the native input method (such as to turn them on and off). While the IME is active, key events (keydown, keypress, keyup) will not be generated. IME input generates text events which are handled by a separate set of handlers. If a key event isn't consumed by the native input method, it will result in a sequence as described below.Each keyboard input results in 3 separate key events: KeyDown, followed by KeyPress, followed KeyUp. All platforms must generate these events in this sequence for every keyboard input (except IME events). Key repeat (automatic generation of keyevents when a key is held down) results in a sequence of a KeyDown event, followed by multiple keypress events, terminated by a KeyUp event. A keypress event should be generated for each platform key repeat event recieved. Each key event has 2 data fields: a virtual key code and a computed
character code. The key code corresponds to the physical key that
was typed. The char code represents the Unicode character that results
from the keyboard input. The char code field is never set during
KeyDown or KeyUp events. It is only set during a KeyPress event in
which the key maps to an actual character. The following table describes
how these data are interpreted for each type of key event:
Key listeners are responsible for knowing when to use key codes and when to use char codes. In particular, the platform must not try to map these data in any way other than as specified in the table above. There are a few special cases that need to be described:
3. Key Event PropogationKey events are DOM events, and follow all the normal DOM event rules for propogation. See http://www.w3.org/TR/WD-DOM-Level-2/events.html. Key event propogation is entirely XP.4. Key Event Processingfrom Tom Pixley (joki@netscape.com)Internally we're using the consumeNoDefault flag. Now ignore that for a second. From the DOM perspective, there are three things that can be done to an event during processing. One is cancelling the default action. This is the equivalent of setting the consume flag. This does *not* prevent further processing. It simply prevents the default action of the system. Now in most cases the system would be the browser itself but since much of the browser is implemented inside the content area this is a little confusing as the system is really now Gecko, not the browser, and since Gecko doesn't generally do too much with the event themselves, cancelling the default action won't buy you much. Then there are two other methods, preventCapture and preventBubble. These methods will, respectively, prevent further handling by lower Nodes in the tree after capturing and prevent further handling by higher Nodes in the tree during bubbling. If you wish a lower or higher level Node to get an event and then stop the event from going further you need to use these flags. The consumeNoDefault flag will only tell the system to stop processing the event but it will still go give the event to all the other DOM handlers. Note that one of the properties of DOM event processing is that an event processor cannot prevent propogation of the event to other listeners on that same node. Since DOM does not provide for ordering of event delivery to listeners on a single node, there is no general mechanism to allow for any communication between them.Key listeners are responsible for knowing when to look at key codes and when to look at char codes. Key listeners should handle keyboard input using the KeyPress event handler. For the editor KeyPress handler, any charCode that is non-zero should be a valid unicode character which can be inserted. Keybindings and accelerators should cancel the event if it shouldn't be inserted in the editor. The keybinding component needs to look at key events prior to the editor component. Character mapping occurs in the platform specific code, prior to the
keypress event being generated. When a key combination, such alt+'s'
could be both a keybinding and a character, the platform code will translate
it into the appropriate Unicode character for the keypress event.
Keybindings need to match against the generated Unicode character in the
keypress event. The only exception to this is keys like Home or Page
Up which don't have a Unicode character representation. For this
case, keybindings should use the keycode in the keypress event.
5. Sample Code
//
// function keys
// misc. keys
// navigation keys
default: isNonPrintable =
false; break;
// logic for determining if a keyevent is printable
return true;
// logic for generating a key down
// logic for generating a key press
// logic for generating a key up
|
|||||||||||||
|
Copyright © 1998-1999 The Mozilla Organization.
Last modified October 7, 1999. |
|||||||||||||