#15384 closed defect (fixed)

[wxMac] wxTextCtrl: WXK_RETURN and WXK_TAB key events are unexpectedly consumed when input context is enabled

Reported by: kbinani Owned by: csomor
Priority: normal Milestone: 3.0.0
Component: wxOSX-Cocoa Version: stable-latest
Keywords: wxTextCtrl wxMac IME Cc: minorinoki@…
Blocked By: Blocking:
Patch: yes

Description

When input method (Kotoeri, Google IME, etc.) is enabled in wxTextCtrl, Return/Tab key event are unexpectedly consumed in wxWigets and not passed to input method.

These key events are usually processed as 'Select next text completion' or 'Finish text completion' by input method.
So we have to ignore these events when input method is enabled, even if wxTE_PROCESS_ENTER or wxTE_PROCESS_TAB style is applied.

Attachments (6)

patch.diff download (1.7 KB) - added by kbinani 14 months ago.
main.cpp download (315 bytes) - added by kbinani 13 months ago.
fig1.jpg download (265.7 KB) - added by kbinani 13 months ago.
fig2.jpg download (202.4 KB) - added by kbinani 13 months ago.
fig3.jpg download (40.4 KB) - added by kbinani 13 months ago.
osxkeyevent.diff download (7.2 KB) - added by minoki 12 months ago.
see comment 5.

Download all attachments as: .zip

Change History (16)

Changed 14 months ago by kbinani

comment:1 Changed 14 months ago by csomor

  • Status changed from new to infoneeded_new

Hi, thanks for the patch, since I don't know the easiest way to test whether things work properly, could you give please me a short how-to for IMEs as of the current osx ?

comment:2 Changed 14 months ago by vadz

  • Status changed from infoneeded_new to new

I'd put the new function declaration in some private OS X header instead of include/wx/utils.h if possible.

And it would be indeed great if somebody else could either test this fix or explain how can it be tested.

Changed 13 months ago by kbinani

Changed 13 months ago by kbinani

Changed 13 months ago by kbinani

Changed 13 months ago by kbinani

comment:3 Changed 13 months ago by kbinani

Hi, I've prepared simple app for testing this problem.
To reproduce this problem, please follow the instructions below:

  1. Build the sample app.
  2. Select 'System Preference' => 'Language & Text' => 'Input Sources' tab.
  3. Search 'Kotoeri' and check it (Fig. 1).
  4. Close 'System Preference'.
  5. Run the sample app.
  6. Focus the text box.
  7. Select 'Kotoeri' (Fig. 2). This changes input mode into 'Japanese'.
  8. Type 'A' key on your keyboard. Then Japanese 'hiragana' letter 'あ' with under line appears to the text box (Fig. 3).
    • The under line represents that the text conversion is not complete. While the under line is displayed, you can select other text conversion candidats by typing space key.
  9. Type return key. This key event is usually (expectedly) send to 'Kotoeri' to complete text conversion. However, the text conversion does not complete(the underline does not disappear).

comment:4 Changed 13 months ago by vadz

  • Milestone set to 3.0

We probably should apply this before 3.0 to make sure text input works correctly when using IME.

comment:5 follow-up: Changed 12 months ago by minoki

  • Cc minorinoki@… added

I think this issue is not specific to wxTextCtrl. If my understanding is correct, any control that handles return key with wxEVT_KEY_DOWN or wxEVT_CHAR potentially have this problem.

Under OSX/Cocoa, in order for the input manager to work, NSResponder -interpretKeyEvents: needs to be called for each key events. In wx, for normal character keys, this is called in "if(IsUserPane()&&!wxevent.CmdDown())" clause in wxWidgetCocoaImpl::DoHandleKeyEvent in src/osx/cocoa/window.mm if the control is a custom control, or if the control is a system control, it is assumably called in the default implementation for -keyDown:. But, for control keys like return or tab, wxWidgets handles them on its own to generate wxEVT_CHAR, as in "if (keycode > 0 && ..." clause in wxWidgetCocoaImpl::DoHandleKeyEvent, whether the control is a system control or not, or the input manager is active or not.
Note that, in any case, if the wxEVT_KEY_DOWN event is handled, NSResponder -interpretKeyEvents: will not be called, and the input manager will not work properly.

Of course, if the control does not consume wxEVT_KEY_DOWN or wxEVT_CHAR events (as the patch by the reporter does by adding "is-IM-active" test), the input manager will work. But, most of the control that handles wxEVT_KEY_DOWN or wxEVT_CHAR (including wxRichTextCtrl, and wxStyledTextCtrl) does not care if the IM is active, and adding "is-IM-active" test to every control that is using wxEVT_KEY_DOWN is not feasible.

To solve the problem and make the input manager work properly, NSResponder -interpretKeyEvents: (or superimpl) must be called *before* wxEVT_KEY_DOWN or wxEVT_CHAR events are generated. My patch attached at #15345 should have done this, but a conflicting change [74613] was introduced and the patch does not apply cleanly now. I'll prepare an updated patch when I have time.
(Maybe wxEVT_KEY_DOWN and wxEVT_CHAR should still be generated in wxWidgetCocoaImpl::DoHandleKeyEvent, if the control is a system control that does not use NSResponder -interpretKeyEvets:)

BTW, I reproduced the issue in "keyboard" sample with "Use text entry".

comment:6 Changed 12 months ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

Changed 12 months ago by minoki

see comment 5.

comment:7 in reply to: ↑ 5 ; follow-up: Changed 12 months ago by minoki

Replying to minoki:

Attached the (updated) patch as osxkeyevent.diff.

comment:8 in reply to: ↑ 7 Changed 12 months ago by kbinani

I have tested the patch 'osxkeyevent.diff' with trunk@r74822, and it works fine. Thank you minoki.

comment:9 Changed 12 months ago by vadz

The explanations in comment:5 make sense to me so even though I don't understand everything in this patch, I'm going to apply it.

Please test key processing with IM in wxOSX 3.0-RC1 which will include this patch, TIA!

comment:10 Changed 12 months ago by VZ

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [74945]) Improve handling of keyboard entry using IME.

Pass the keyboard events to the IME before generating our events for them, the
IME may need them for its own use.

Closes #15384.

Note: See TracTickets for help on using tickets.