[Webkit-unassigned] [Bug 16735] keyboard events created with DOM have keyCode and charCode of 0; thus they aren't handled correctly internally

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=16735





--- Comment #11 from Darin Adler <darin at apple.com>  2009-11-15 14:41:20 PST ---
It makes sense to have mappings from key identifiers to key code and character
code. Ideally the data could be shared by the PlatformKeyEvent code for the
various platforms that has to map keys to key identifiers, key codes, and
character codes. There may need to be some exceptions to get every last key to
work correcty, but for the most part the same data table should be able to be
used both to help in the mapping of a platform's keys to key identifiers, key
codes, and character codes, and to map from a key identifier to a key code and
character code.

I also think the direction we should go in is to compute and store the key code
and the character code in the KeyboardEvent object rather than dynamically
fetching them from the PlayformKeyboardEvent when asked.

After construction/init time, the PlatformKeyboardEvent would be used only in
cases where it must. Specifically that means only in the keyEvent function,
which should be renamed underlyingPlatformEvent to make it seem less "normal"
to dig down to that level. Any code that does must have a good reason.

(Besides renaming m_keyEvent to m_underlyingPlatformEvent, we should use an
OwnPtr.)

To investigate how this is used I took at look at all the call sites. There
were three categories:

    1) When sending events to plug-ins. This is probably something we should
probably keep longer term. It's asking a lot for plug-ins to be able to handle
events created by the DOM. Would probably require one of the newer plug-in
architectures to do it cleanly.

    2) When mapping events to editing commands on Mac OS X in -[WebHTMLView
_interceptEditingKeyEvent:shouldSaveCommands:], because the AppKit API in
question needs an NSEvent. This means that any commands that work through the
Mac OS X editing key bindings won't work with DOM events. That includes a lot
of basic stuff, and would be good to try to address this by creating an
appropriate NSEvent if there is no underlying event already. Perhaps there
there would be problems where the NSEvent would cause input methods to
malfunction if we had a key down without a key up or malformed in other ways.
We also would have to consider whether to cache the NSEvent we created.

    3) When handling events in analogous functions to (2) on other platforms.
These various functions mostly started as copies of the Win code or have a
similar function:

        Chromium: WebKeyboardEventBuilder::WebKeyboardEventBuilder,
            EditorClientImpl::interpretKeyEvent and
            EditorClientImpl::handleEditingKeyboardEvent
        GTK: EditorClient::handleKeyboardEvent and
            EditorClient::handleInputMethodKeydown
        Haiku: EditorClientHaiku::handleKeyboardEvent
        Qt: EditorClientQt::handleKeyboardEvent
        Win: WebView::handleEditingKeyboardEvent
        Wx: EditorClientWx::handleEditingKeyboardEvent and
            EditorClientWx::interpretKeyEvent

    I can't tell if any of these non-Mac-OS-X functions really need any data
that comes only from the native event, the way the Mac OS X code path does. It
seems likely they do things this way largely because they were inspired by the
Mac OS X code. I suspect we could probably do all of this in a way that would
work with synthetic DOM events instead of requiring actual platform events.
Probably an easier project than (2) above where we'd have to work with the Mac
OS X editing key mapping machinery.

I'd love to fix first (3) and then (2) so we could do any non-plug-in action
with a DOM keyboard event. I'm not saying all that should or could be covered
by this one bug report.

To muddy the waters further, I'm not sure the version of keyboard event init
function and keyboard event class we have here matches the DOM Level 3 standard
any longer. We may have to do some work to keep existing callers working and
make more modern code work as well. It seems to me that if keyCode and charCode
are part of the object, then the constructor should simply take in values for
those.

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