Bug 14522 – REGRESSION: Cannot paste into an active inline input area

• Status: RESOLVED
• Resolution: FIXED
• Component: Text

[Alexey Proskuryakov]

Steps to reproduce:
1) Type something into an input field using Kotoeri Hiragana.
2) Without confirming inline input, press Cmd+V.

Expected results: the inline input area should be automatically confirmed, text from the clipboard should be pasted.
Results: nothing happens.

This is a regression from Tiger WebKit. Tested with r23984.

[Oliver Hunt]

Are you sure about this? I can't reproduce at all

I typed typed 'abc', cmd-a, cmd-x -- 'abc' now in clipboard -- switched to kotoeri hiragana, typed toukyou, then cmd-v and it confirmed and pasted.

i repeated but used arrow keys to step back into the  inline hole and paste still did the right thing...

[Alexey Proskuryakov]

You are right, there seems to be some kind of operator mistake. Now I can only reproduce this with an earlier nightly using Kotoeri, but my own input method still has a very similar problem.

I'm going to investigate this better.

[Alexey Proskuryakov]

Created attachment 15428 [details]
an input method for testing

[Alexey Proskuryakov]

So, this problem is not reproducible with Kotoeri anymore, but it still happens with my input method. The steps to reproduce are the same.

The difference seems to be in the way pasting in handled by these IMs. Given a Cmd+V event, RuSwitcher confirms the inline input area (which is translated to a -[WebHTMLView insertText:] call by NSTSMEventHandler), and returns FALSE from the handler to let the application handle Cmd+V.

It seems that WebKit thinks that the event was already handled, and doesn't let AppKit process it.

IIRC, the RuSwitcher approach was necessary for compatibility with some clients, and TOT WebKit is the only client where it doesn't work.

[David Kilzer (:ddkilzer)]

<rdar://problem/5319438>

[Oliver Hunt]

Okay, i've looked at this now using RuSwitcher.

This problem is due to that wonderful weakness of Cocoa, namely the call to interpretKeyEvents does not return a value to indicate that the IME has or has not handled an event.  To work around this we basically try to guess whether the IME has consumed the event (in which case we should not forward).  

Because RuSwitcher sends an insertText message we believe it has actually handled the event, so we stop forwarding it.

[Oliver Hunt]

Okay, have done a bit more looking.  As far as webkit is consumed, you calling insertText: at this point is wrong -- the expected behaviour is that you ignore cmd-v as you are not processing it.

This means webkit passes the event to appkit, appkit triggers the paste, and the paste makes webkit commit the marked region.

RuSwitcher should not be causing side effects for any event that is not directly controlling its behaviour, if you just ignored the cmd-v then everything should just work.

Unfortunately the cocoa/appkit IM model is designed around the idea of the IM being the last component to be passed a raw event, eg. that hot/shortcut keys (like cmd-v) would already have been handled.  The DOM event model requires that we don't do this, which kind of messes with behaviour and is responsible for most of our IM woes.

[Alexey Proskuryakov]

(In reply to comment #7)
> Okay, have done a bit more looking.  As far as webkit is consumed, you calling
> insertText: at this point is wrong -- the expected behaviour is that you ignore
> cmd-v as you are not processing it.

Unfortunately, this was necessary for compatibility with clients that couldn't handle a paste when there was an active inline input area :(

I believe this behavior of RuSwitcher is correct from TSM point of view, even though it causes problems on TOT WebKit.

[Oliver Hunt]

A solution has presented itself!

AppKit will send  noop: to doCommandBySelector

The solution is relatively trivial, but requires a bit of testing first to make sure nothing has gone off the deep end.

[Oliver Hunt]

Fix landed r24505