Combine the WM_CHAR with WM_KEY* for key event flow.

win8/metro_driver/metro_driver_win7.cc

Index: win8/metro_driver/metro_driver_win7.cc
diff --git a/win8/metro_driver/metro_driver_win7.cc b/win8/metro_driver/metro_driver_win7.cc
index 3ace04caee0a06327e53b95281b2c12e2be42b5c..1bcf1a8ebfb36823d554885f3735ad47fe5aa584 100644
--- a/win8/metro_driver/metro_driver_win7.cc
+++ b/win8/metro_driver/metro_driver_win7.cc
@@ -463,7 +463,6 @@ class CoreDispatcherEmulation :
     MSG msg = {0};
     while((::GetMessage(&msg, NULL, 0, 0) != 0) && g_window_count > 0) {
       ProcessInputMessage(msg);
-      ::TranslateMessage(&msg);
       ::DispatchMessage(&msg);

[yukawa, 2015/08/05 21:23:36]

Can you leave a comment about why ::TranslateMessage isn't called here.

[Shu Chen, 2015/08/06 01:35:51]

Done.

     }
     // TODO(cpu): figure what to do with msg.WParam which we would normally
@@ -913,6 +912,20 @@ class CoreWindowEmulation
     switch (msg.message) {
       case WM_KEYDOWN:
       case WM_KEYUP: {
+        ::TranslateMessage(&msg);
+        // Peek & remove the following messages in the message queue.
+        //  - WM_CHAR (0x0102)
+        //  - WM_DEADCHAR (0x0103)
+        // And only process WM_CHAR message in browser.
+        MSG char_msg;
+        while (::PeekMessage(&char_msg, msg.hwnd, WM_CHAR, WM_DEADCHAR,
+                             PM_REMOVE)) {
+          if (char_msg.message == WM_DEADCHAR)
+            continue;
+          mswr::ComPtr<winui::Core::ICharacterReceivedEventArgs> char_args;
+          char_args = mswr::Make<KeyEvent>(char_msg);
+          character_received_handler_->Invoke(this, char_args.Get());
+        }
         mswr::ComPtr<winui::Core::IKeyEventArgs> event_args;
         event_args = mswr::Make<KeyEvent>(msg);
         KeyEventHandler* handler = NULL;
@@ -925,15 +938,6 @@ class CoreWindowEmulation
         break;
       }
 
-      case WM_CHAR:
-      case WM_DEADCHAR:
-      case WM_UNICHAR: {

[yukawa, 2015/08/05 21:23:36]

I supposed removing WM_UNICHAR support does not affect the goal of this CL, but
may still have some non-trivial effect.  If we intentionally do this, it should
be commented in the CL description.

[Shu Chen, 2015/08/06 01:35:51]

Removing WM_UNICHAR here doesn't change the existing behavior.
Please note that RemoteInputMethodWin::DispatchKeyEvent() doesn't support
WM_UNICHAR.
https://code.google.com/p/chromium/codesearch#chromium/src/ui/base/ime/remote...

So I think the change here is pretty safe.

[yukawa, 2015/08/06 01:45:51]

Is there any chance that unhandled WM_UNICHAR was translated into multiple
WM_CHAR in DefWindowProc?

[Shu Chen, 2015/08/07 07:15:23]

I've removed the WM_DEADCHAR & WM_UNICHAR here, and only handle WM_CHAR.
Because it is useless to do Invoke() for WM_DEADCHAR & WM_UNICHAR.
As for WM_UNICHAR case, accordingly to MSDN doc:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646288(v=vs.85).aspx
 > If wParam is not UNICODE_NOCHAR, return FALSE. The Unicode  DefWindowProc
posts a WM_CHAR message with the same parameters and the ANSI DefWindowProc
function posts either one or two WM_CHAR messages with the corresponding ANSI
character(s).

So, application doesn't need to handle WM_UNICHAR, because DefWindowProc() can
take care of things nicely.

-        mswr::ComPtr<winui::Core::ICharacterReceivedEventArgs> event_args;
-        event_args = mswr::Make<KeyEvent>(msg);
-        character_received_handler_->Invoke(this, event_args.Get());
-        break;
-      }
-
       default:
         return false;
     }