Combine the WM_CHAR with WM_KEY* for key event flow.

base/message_loop/message_pump_win.cc

Index: base/message_loop/message_pump_win.cc
diff --git a/base/message_loop/message_pump_win.cc b/base/message_loop/message_pump_win.cc
index 10e308aa9dc3406ad5d1f02c5edca8e6a83573c9..e141c7cdb1b11236d5c56ee338364249bbf9bf49 100644
--- a/base/message_loop/message_pump_win.cc
+++ b/base/message_loop/message_pump_win.cc
@@ -400,10 +400,12 @@ bool MessagePumpForUI::ProcessMessageHelper(const MSG& msg) {
   }
   if (action & MessagePumpDispatcher::POST_DISPATCH_QUIT_LOOP)
     state_->should_quit = true;
-  if (action & MessagePumpDispatcher::POST_DISPATCH_PERFORM_DEFAULT) {
-    TranslateMessage(&msg);
+  // Don't call TranslateMessage() here but call TranslateMessage() in

[robliao, 2015/08/11 18:39:27]

TranslateMessage+DispatchMessage is generally idiomatic Windows message pump
code. Separating them generally means you really had no other way to accomplish
what you want.

A few questions:
What keeps Chrome IME's from responding to the WM_KEYDOWN/UP and WM_CHAR in
sequence? TranslateMessage just sends the WM_CHAR to the thread's message queue.

Since we're directly dispatching the WM_KEYDOWN/WM_KEYUP messages without
translations, will there be message ordering changes that might cause problems?
Before, WM_*CHARs would be posted before we handle the message. Now they won't.

Will this subsume all Windows IME functionality?

And a comment:
If we keep this, keep the braces for the if and move this comment to right
before DispatchMessage. This comment directly addresses the absense of
TranslateMessage and should immediately precede the DispatchMessage call.

[Shu Chen, 2015/08/12 08:00:11]

In MSDN for TranslateMessage, it says "If applications process virtual-key
messages for some other purpose, they should not call TranslateMessage..." which
means it is not rare to not call TranslateMessage in the message loop.
Chrome IMEs will be implemented as an extension. Once it is activated, Chrome
will forward all the key events to the extension. The extension can decide
whether the key event is consumed.
Let's see a concrete example when user pressed { Shift + 2 }:
 - WM_KEYDOWN(VKEY_2/SHIFT) happened.
 - Chrome forwards it to the extension, which is not interested.
 - WM_CHAR('@') happened.
 - Chrome forwards it to the extension, which is interested & consumed it.
In this case, the IME is only interested in "@" key, which could be Shift+2 in
US layout, or single quote key in UK layout.
However, the WM_KEYDOWN message has already happened before IME can make
decision of whether to consume the key.
In a web page, according to W3C standard, if a key is consume by IME, "keydown"
event with 229 "keycode" should be generated. Which means, when Chrome processes
the WM_KEYDOWN, it needs to hold it until the it gets the result from WM_CHAR
processing.
And that is infeasible to implement, because if Chrome holds the WM_KEYDOWN, it
doesn't know when to dispatch it if there is no WM_CHAR afterwards.
This example demonstrates that combining WM_KEY* with WM_CHAR is necessary to
support Chrome IMEs.
IMF (e.g. InputMethodWin) is the first guy who handles the key events in Chrome.
Well, before IMF, there is HWNDMessage. But it basically does nothing but
forward the message.
As I've described in the CL description, the order change may be less risky than
we thought.
Yes, I've verified the Windows native IMEs in win7/win8 & win8 metro.
Done.

[robliao, 2015/08/12 18:04:12]

While MSDN mentions that you don't have to call TranslateMessage depending on
your use case, omitting that call is pretty rare because you lose WM_CHAR and
WM_SYSCHAR.
http://blogs.msdn.com/b/oldnewthing/archive/2005/04/26/412116.aspx

http://stackoverflow.com/questions/3152011/why-are-translatemessage-and-dispa...

http://www.winprog.org/tutorial/message_loop.html

Can the IME instead look ahead in the message loop via PeekMessage instead for
the WM_CHARs when receiving a WM_KEYDOWN? This is already done with the
TranslateMessage+PeekMessage combo in InputMethodWin. You'd simply move the
TranslateMessage back to here.
What if the user actually wants to use the Windows native IME? IIRC, the Windows
Native IME kepts track of usage patterns to tailor suggestions to the user.

[Shu Chen, 2015/08/13 02:09:26]

Good idea. Done.
Native IME receives the key event before Chrome receives it.
So when pressed a key with a CJK IME activated, WM_KEYDOWN with key_code==229
will arrive at Chrome. Calling TranslateMessage() on that message will result in
WM_IME_* messages.
Chrome IMEs can simply ignore the key event with key_code==229, so that OS level
IME can work as normal.

+  // InputMethodWin, so that the WM_KEYDOWN/WM_KEYUP & WM_CHAR can be combined
+  // for key event flow. The combination of key events is required for Chrome
+  // IMEs, which can do IME related actions based on the single key event.
+  if (action & MessagePumpDispatcher::POST_DISPATCH_PERFORM_DEFAULT)
     DispatchMessage(&msg);
-  }
 
   return true;
 }