MacViews: Change insertTextInternal to correctly handle IME character input.

ui/views/cocoa/bridged_content_view.mm

Index: ui/views/cocoa/bridged_content_view.mm
diff --git a/ui/views/cocoa/bridged_content_view.mm b/ui/views/cocoa/bridged_content_view.mm
index 9654302cd0326c8571193c5d9c0ae15a8bc70681..af62569c71421ffda83811c8ec3e060d0398d2f6 100644
--- a/ui/views/cocoa/bridged_content_view.mm
+++ b/ui/views/cocoa/bridged_content_view.mm
@@ -437,11 +437,22 @@ - (void)insertTextInternal:(id)text {
   if (textInputClient_ && ![self activeMenuController]) {
     // If a single character is inserted by keyDown's call to
     // interpretKeyEvents: then use InsertChar() to allow editing events to be
-    // merged.
-    if (isCharacterEvent)
-      textInputClient_->InsertChar(GetCharacterEventFromNSEvent(keyDownEvent_));
-    else
+    // merged. We use ui::VKEY_UNKOWN as the key code since it's not feasible to
+    // determine the correct key code for each unicode character. Also a correct
+    // keycode is not needed in the current context. Send ui::EF_NONE as the key
+    // modifier since |text| already accounts for the pressed key modifiers.

[tapted, 2016/07/28 02:01:06]

It might be worth raising a bug with the IME folks to just give `InsertText` a
boolean argument like "allow merge".. But this is OK for now

+
+    // Also, note we don't use |keyDownEvent_| to generate the synthetic
+    // ui::KeyEvent since for text inserted using an IME, [keyDownEvent_
+    // characters] might not be the same as |text|. This is because
+    // |keyDownEvent_| will correspond to the event that caused the composition
+    // text to be confirmed, say, Return key press.
+    if (isCharacterEvent) {
+      textInputClient_->InsertChar(ui::KeyEvent([text characterAtIndex:0],
+                                                ui::VKEY_UNKNOWN, ui::EF_NONE));
+    } else {
       textInputClient_->InsertText(base::SysNSStringToUTF16(text));
+    }
     return;
   }