[Webkit-unassigned] [Bug 15232] keyCode/charCode/which not reported correctly

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15232





------- Comment #3 from oliver at apple.com  2007-09-18 14:46 PDT -------
First up, i'll say this: keyCode and charCode are both ugly -- especially in
the context of international input

The key event models used by IE and Firefox are different, and a spent a *long*
time a couple of months ago fixing Safari's key event model to maximise
compatibility with sites that depend on bizarre firefox behaviour, or the
slightly more sane ie model.  Here's the description i sent to the web-api
list:

Anyhoo, just for reference the WebKit key press handling is (approximately) as
follows:

function handleKeyEvent(event) {
    if (event.isKeyUpEvent) {
        // Fire a DOM KeyUp event
        fireKeyUpEvent(event);
        return;
    }

    // We need to call the input method now as the our behaviour changes
according to whether
    // the event was handled by the Input Method
    if (inputMethod.handleEvent(event)) {
        // The event was handled by the Input Method, if the IM would
insert/change the current composition as a result
        // of this event then the change has *already* happened
        // A number of sites break under IMs if we just send the correct
keyCode for the keyDown for an IM handled event
        // So we set the keyCode to 229, which matches IE :-/
        event.keyCode = 229;
        // Fire a DOM keydown event
        fireKeyDownEvent(event);
        return;
    }

    // Even though the IM has not "handled" the event the content of the text
region may have
    // changed (eg. confirmation of a composition with various Korean IMs)
    bool defaultHandled = fireKeyDownEvent(event);
    defaultHandled = fireKeyPressEvent(event) || defaultHandled;
    if (!defaultHandled)
        fireTextInputEvent(event);
}

This behaviour is not something that should be used to standardise on as it has
been designed with the goal of website compatibility rather than to be "nice".

Important things to note:
 * preventDefault on KeyDown will *not* prevent KeyPress events from being
fired (this matches Firefox behaviour, and is needed for a couple of sites)
 * preventDefault on KeyDown *or*KeyPress will prevent the TextInput event, eg.
no text will be inserted
 * autorepeat keys trigger keydown and keypress events (otherwise we break
sites that expect keydown for all keyevents)
 * KeyPress and TextInput events are *not* fired if an Input Method has handled
the event
 * the keyCode for a KeyDown event that has been handled by the Input Method
will be 229, this is needed to not break a number of sites -- might be
reducible to only mask the keycode for control keys, but that's difficult to
verify.  People do really stupid things on keydown.
 * the Input Method *may* have side effects that occur before any key event has
been fired.  This is kind of icky, but matches IE behaviour, but i strongly
doubt any sites exist that depend on this behaviour.



-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.