Entering japanese characters into html inputs (problem with IME support?)

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Turn on a Japanese keyboard:
System Prefeferences -> Language & Text -> Input Sources -> Kotoeri 

The screenshot: http://dl.dropbox.com/u/916578/Screenshots/jap_keyboard.png

2. Change the current system keyboard to "Katakana".

The screenshot: http://dl.dropbox.com/u/916578/Screenshots/japanese_katakana.png

2. Run cefclient app.
3. Insert "a" character into the html input field.

The screenshot: http://dl.dropbox.com/u/916578/Screenshots/japanese_problem.png 

What is the expected output? What do you see instead?

Expected output: ア
I see: a

What version of the product are you using? On what operating system?

OSX Lion

Original issue reported on code.google.com by t.kape...@gmail.com on 23 Mar 2012 at 4:55

[GoogleCodeExporter]

I'm using cef_binary_1.963.439_macosx.

Original comment by t.kape...@gmail.com on 23 Mar 2012 at 4:59

[GoogleCodeExporter]

This problem seems not to exist on Windows 7/8.

Original comment by t.kape...@gmail.com on 23 Mar 2012 at 7:39

[GoogleCodeExporter]

Can anybody check if the problem exists if cefclient is build on Snow 
Leopard/Xcode 3.2 (or something similar as this)? Maybe the problem is 
OSX/Xcode version related?

Original comment by t.kape...@gmail.com on 25 Mar 2012 at 12:14

[GoogleCodeExporter]

I have the same problem as described here: 
http://code.google.com/p/chromium/issues/detail?id=11952 

But this bug was fixed in the Chromium a few years ago...

I've built the CEF from source (using automate.py).

CEF Revision: 550
Chromium Revision: 122508

The problem still exists. :(

Original comment by t.kape...@gmail.com on 26 Mar 2012 at 10:40

[GoogleCodeExporter]

CEF does not implement the NSTextInput protocol. See WebWidgetHost::KeyEvent in 
webwidget_host_mac.mm. Patches welcome.

Original comment by magreenb...@gmail.com on 26 Mar 2012 at 11:57

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've started working on this issue, I'll attach a patch once I have something 
functional.

Original comment by mihai.o....@gmail.com on 22 May 2012 at 3:53

[GoogleCodeExporter]

I've enabled IME support, however, there's still some work to do regarding the 
positioning of the rectangle where you choose which symbol to enter.
Will come with a patch for review in a few days.

Original comment by mihai.o....@gmail.com on 24 May 2012 at 9:06

[GoogleCodeExporter]

I've added a patch with a fix for this issue (see the attachment).
The implementation is mostly based on the one present in the chromium content.  

Original comment by mihai.o....@gmail.com on 25 May 2012 at 1:01

Attachments:

• enableIME_Mac.patch

[GoogleCodeExporter]

The previous patch ignored IME punctuation. In other words, if you selected 
Pinyin-Simplified and pressed the '.' key, the output was '.' instead of '。'

I've attached another patch that contains both the fix for enabling IME input 
and correct handling of IME punctuation.

Original comment by mihai.o....@gmail.com on 28 May 2012 at 8:49

Attachments:

• enableIME_Mac_punctuation.patch

[GoogleCodeExporter]

The patch above had the following problem: When editing a textarea, pressing 
Enter had no effect.
Re-adding the patch with a minor adjustment that fixes this problem. 

Original comment by mihai.o....@gmail.com on 28 May 2012 at 11:33

Attachments:

• enableIME_Mac_punctuation_enter.patch

[GoogleCodeExporter]

Overall, the patch looks good except for indentation and line wrapping style 
issues. I'll test it more tomorrow.

Original comment by magreenb...@gmail.com on 29 May 2012 at 10:09

[GoogleCodeExporter]

There seems to be a bug with your patch where, if I type the letter 'a' in a 
text field as described in the original issue report, I then have to hit the 
delete key twice in order to delete the resulting 'ア'. In TextEdit, for 
example, only a single delete key press is required.

Original comment by magreenb...@gmail.com on 30 May 2012 at 9:17

[GoogleCodeExporter]

I've investigated this problem and this is what I've found: 
When the underlined text has only one character and you press the 
backspace/delete key, none of the setMarkedText or insertText methods are 
called.
This means that the place where we have a chance to handle the delete key is 
the keyEvent handler.

The workaround found for the issue you've mentioned is straight-forward, when 
the underlined text has exactly one character, we detect if a backspace/delete 
is pressed and forward it to Webkit.
Obviously, this is not the desired way of fixing the problem, but since none of 
the methods mentioned above is called, I couldn't find a more elegant solution.
I've done some testing with "Katakana" and "Pinyin-Simplified" on both Snow 
Leopard and Lion and didn't find any other problems.
I've added the patch with my workaround to this message.

Also, I'd like to ask you: since chunks of the code in this patch are copied 
from Chromium, are there any copyright concerns regarding this?

Thanks

Original comment by mihai.o....@gmail.com on 6 Jun 2012 at 2:44

Attachments:

• IME_Mac.patch

[GoogleCodeExporter]

Thanks for looking into the problem. Many CEF source files include code from 
Chromium. All source files have correct copyright headers as required by the 
project licenses.

Original comment by magreenb...@gmail.com on 6 Jun 2012 at 3:00

[GoogleCodeExporter]

Committed as revision 676 and 677 with minor style changes.

Original comment by magreenb...@gmail.com on 7 Jun 2012 at 6:44

• Changed state: Fixed