[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 bugzilla-daemon at webkit.org
Wed Nov 18 14:26:28 PST 2009


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





--- Comment #12 from Daniel Bates <dbates at webkit.org>  2009-11-18 14:26:26 PST ---
(In reply to comment #11)
> 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 agree, it would be ideal if we could share the same lookup table. I made an
attempt to do so by categorizing the platform-independent keyIdentifier in
KeyboardEvents::keyIdentifiers() and the platform-dependent ones in
PlatformKeyboardEvents::keyIdentifiers(). And the way I structured the lookup,
by looking up an identifier first in the platform-specific table, allows for
there to be platform-specific exceptions to the otherwise platform-independent
table.

> 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.

(A) These seems like a separate issue from this bug or would be better
addressed in a separate bug. Some of the "platform-specific" aspects may in
actuality be platform-independent (i.e. can be moved into KeyboardEvents). I'll
look into this some more.

> 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.

Right. I think this will naturally follow from addressing (A), and is probably
best addressed in a separate bug.

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

I have filed bug #31647 to change KeyboardEvent::m_keyEvent to 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:

For the following, I have listed only the methods that explicitly call
functionality defined in an instance of PlatformKeyboardEvent.

> 
>         Chromium: WebKeyboardEventBuilder::WebKeyboardEventBuilder,

This uses methods PlatformKeyboardEvent::text,
PlatformKeyboardEvent::unmodifiedText, and
PlatformKeyboardEvent::nativeVirtualKeyCode.

>             EditorClientImpl::interpretKeyEvent and

This seems that it can be re-written without the use of PlatformKeyboardEvent.
See (*).

>             EditorClientImpl::handleEditingKeyboardEvent

This uses methods PlatformKeyboardEvent::text, and
PlatformKeyboardEvent::isSystemKey. See (*).

>         GTK: EditorClient::handleKeyboardEvent and

This uses method PlatformKeyboardEvent::text, and PlatformKeyboardEvent::type
(**).

>             EditorClient::handleInputMethodKeydown

This method is empty. It only has the comment "We handle IME within chrome".

>         Haiku: EditorClientHaiku::handleKeyboardEvent

This uses method PlatformKeyboardEvent::windowsVirtualKeyCode,
PlatformKeyboardEvent::type (**), and PlatformKeyboardEvent::text. See (*).

>         Qt: EditorClientQt::handleKeyboardEvent
>         Win: WebView::handleEditingKeyboardEvent

This uses methods PlatformKeyboardEvent::text,
PlatformKeyboardEvent::isSystemKey, and PlatformKeyboardEvent::type (**).

>         Wx: EditorClientWx::handleEditingKeyboardEvent and

This uses methods PlatformKeyboardEvent::text and PlatformKeyboardEvent::type
(**).

>             EditorClientWx::interpretKeyEvent

This uses method PlatformKeyboardEvent::type (**).

(*) Calls PlatformKeyboardEvent::altKey(), PlatformKeyboardEvent::ctrlKey(),
PlatformKeyboardEvent::metaKey(), or PlatformKeyboardEvent::shiftKey(). But
these seem unnecessary on the surface, since we may able to substitute them for
the respective KeyboardEvent calls, which are inherited from
UIEventWithKeyState.

(**) We may able to substitute PlatformKeyboardEvent::type for
KeyboardEvent::type, which is inherited from Event (note: KeyboardEvents
extends UIEventWithKeyState extends UIEvent extends Event).

> 
>     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.

Right. I think it would be best if we address these issues in separate bugs.

> 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.

Yes, I am aware that our API differs from the DOM Level 3 standard. My thought
was to first fix this bug then update our API to match the spec (which is bug
#13368).

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



More information about the webkit-unassigned mailing list