Full support of IME input in plugins

jonas echterhoff jonas at unity3d.com
Thu Feb 18 06:50:00 PST 2010

I hope that this is the correct place for such discussions.

Here's one thing I've been wondering about. We'd like our plugin to fully support IME input, for languages where multiple key presses are required to bring up a character, like Korean, Japanese or Chinese. 

By fully support, I mean that the composition of strings should be handled by our plugin, so that text is composited in place inside the text fields of the plugin, with selection windows popping up in the correct locations relative to the plugin - in contrast to some solution where the browser opens a text field, and sends the resulting string to the plugin, as some current implementations seem to be like. This is not sufficient for our use, for one because actually rendering the composition string inside the plugin view looks more natural, but also, because we want to have full control on whether character composition should take place or not (for example while playing a game, key presses should have immediate action - when editing a text field, key presses should be interpreted according the the selected Input method).

Currently, this works fine on windows, as windows passes all the required messages to the plugin. On Mac OS X we were able to get it to work by snatching Carbon events away from the browser, but this is a hack, and no longer possible in out-of-process solutions like Safari 4. The new Cocoa event model does not give us all the events we need, it will just send complete strings to the plugin using text entry events (at least according to the specification - the current implementation in Safari appears to be broken). A brief look at the Pepper NPAPI specification also seems to only have limited support for IME input.

What we would ideally need in addition to that is custom events for any changes to the composition string (in addition to raw key down events) and an method to give the current screen location of text input to the IME.

Are there any such plans? Where could such a change be proposed to the Pepper event model?


More information about the plugin-futures mailing list