Opened 5 years ago

Closed 5 years ago

Last modified 16 months ago

#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 Version: stable-latest
Keywords: wxTextCtrl wxMac IME Cc: minorinoki@…
Blocked By: Blocking:
Patch: yes


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 5 years ago.
main.cpp download (315 bytes) - added by kbinani 5 years ago.
fig1.jpg download (265.7 KB) - added by kbinani 5 years ago.
fig2.jpg download (202.4 KB) - added by kbinani 5 years ago.
fig3.jpg download (40.4 KB) - added by kbinani 5 years ago.
osxkeyevent.diff download (7.2 KB) - added by minoki 5 years ago.
see comment 5.

Download all attachments as: .zip

Change History (18)

Changed 5 years ago by kbinani

comment:1 Changed 5 years 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 5 years 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 5 years ago by kbinani

Changed 5 years ago by kbinani

Changed 5 years ago by kbinani

Changed 5 years ago by kbinani

comment:3 Changed 5 years 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 5 years 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 5 years 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/ 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 5 years ago by csomor

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

Changed 5 years ago by minoki

see comment 5.

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

Replying to minoki:

Attached the (updated) patch as osxkeyevent.diff.

comment:8 in reply to: ↑ 7 Changed 5 years ago by kbinani

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

comment:9 Changed 5 years 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 5 years 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.

comment:11 Changed 17 months ago by arturs

Hello all! This is my first post as a registered user here. Firstly, thank you, as this page was helpful.

I'd like to add that arrow keys do not work for IME when used in controls that also handle these keys as accelerators. The reason is key equivalent events are treated before normal key events. In case they are handled, normal key events flow is not reached.
Probably, to fix this, key equivalent events also need to be re-directed to IME and treated as accelerators later in doCommandBySelector() in case IME hasn't consumed them.

I succeeded to work this around, but I believe this is not a clean fix from wxWidgets point of view and I would prefer to get a better solution.

EDIT: Arrow keys were actually not treated as accelerators, but sent as key down events in the patched key equivalent handling. Please disregard this.

Last edited 16 months ago by arturs (previous) (diff)

comment:12 Changed 17 months ago by vadz

Handling arrow keys as accelerators in text controls seems rather unusual, so I'm not sure how big of a problem is this in practice, but any improvements would still be welcome, of course, so if you can make a patch implementing your idea, please don't hesitate to submit it (as a separate new ticket please to make things simpler to manage). TIA!

Note: See TracTickets for help on using tickets.