[Webkit-unassigned] [Bug 10871] REGRESSION: IME key events different in nightly

[bugzilla-daemon at webkit.org]

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


darin at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|BugDayReviewed              |
                 CC|                            |darin at apple.com,
                   |                            |adele at apple.com




------- Comment #8 from darin at apple.com  2007-02-11 13:20 PDT -------
(In reply to comment #7)
> 2) keypress is sent when an input method doesn't handle the event (i.e. when
> the IM has returned a "not handled" status, or a plain keyboard layout is being
> used). This is also when form submission etc takes place. Canceling the event
> cancels default processing.

This is quite difficult to implement given the way we work with AppKit. In
AppKit, a single interpretKeyEvents: method both sends events to input methods
and dispatches commands. So if we want to interpret the key event before
sending a keypress, so we can tell if the input method handles it or not, then
we will also be dispatching commands like cut, motion with arrow keys, and the
delete keys. That means there won't be a keypress for delete or arrow key
presses, and I think there should be. This is going to be tricky to get right.

> 3) I'm not really sure when textInput is supposed to be sent. I guess it's only
> meaningful for final text, i.e., typing into inline hole shouldn't dispatch
> this event, but confirming it should do so. Typing with a plain keyboard or
> entering text via Character Palette should probably dispatch it, as well.
> Pasting from clipboard probably shouldn't.

That's right. My patch attached to bug 10010 implements the rule you mention
here.

The DOM Level 3 specification says that pasting should dispatch it if the
pasted text is plain text, but I think that's a bad idea. Whether text is
styled or not should not affect which events are dispatched!

> Looks like canceling textInput cannot prevent the text from being inserted -
> after all, DOM already has the inline hole content, correct? Canceling keypress
> prevents typing with a plain keyboard and default actions.

In my opinion preventing default behavior on a textInput event should cause the
content from the inline hole to be discarded.


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