Input method blocked in the presence of modal components

We recently got some feedback from our Japanese users: IMEs do not respond in a text input dialog despite working perfectly fine in our app’s main window. The dialog is basically an AlertWindow with a TextEditor added to desktop after calling enterModalState.

I tried removing enterModalState from the dialog spawning code and was able to regain IME support. I looked into JUCE library code for anything that both has to do with key presses and component modal state and found this line in HWNDComponentPeer::doKeyDown() very fishy.

So this means a key down event gets consumed if any component is made modal, even if the event is on the modal component. I tried removing this condition, shortening this line to return used; and this seems to solve the problem. The question is: are there any side-effects? Did I just fixed a bug or broke a bunch of things as well?


This problem only occurs when running as a VST plugin. It does not affect the standalone version.

I also propose the following fix just to be cautious of breaking anything.

if (auto modalComponent = Component::getCurrentlyModalComponent())
    // Consume the event if it's sent to a non-modal ComponentPeer.
    if (modalComponent -> getPeer() != this)
        return true;

return used;