Bug 1336331 NativeKey::GetFollowingCharMessage() should try to use GetMessage() when PeekMessage() failed to remove a char message from the queue and there is still existing a char message r=m_kato

I think that when PeekMessage(PM_REMOVE) failed to remove a char message but next key message is still a char message, it may be possible that the odd keyboard layout or utility hook only PeekMessage(PM_NOREMOVE) and GetMessage().  If so, we can explain what occurs in this case.

I'm still not sure this fixes the case of bug 1336322 comment 0, but we should try to do this because I don't have better idea.

MozReview-Commit-ID: CxoO24n167t

--HG--
extra : rebase_source : c00b86166a345eec18fa2de74698f6e8859364b8

widget/windows/KeyboardLayout.cpp

@@ -2975,21 +2975,23 @@ NativeKey::GetFollowingCharMessage(MSG& aCharMsg)
         nextKeyMsg = nextKeyMsgInAllWindows;
         continue;
       }
-      if (MayBeSameCharMessage(nextKeyMsgInAllWindows, nextKeyMsg)) {
-        // The found char message still in the queue, but PeekMessage() failed
-        // to remove it only with PM_REMOVE.  Although, we don't know why this
-        // occurs.  However, this occurs acctually.
-        // Try to remove the char message with GetMessage() again.
-        if (WinUtils::GetMessage(&removedMsg, mMsg.hwnd,
-                                 nextKeyMsg.message, nextKeyMsg.message)) {
-          MOZ_LOG(sNativeKeyLogger, LogLevel::Warning,
-            ("%p   NativeKey::GetFollowingCharMessage(), WARNING, failed to "
-             "remove a char message, but succeeded with GetMessage(), "
-             "removedMsg=%s, kFoundCharMsg=%s",
-             this, ToString(removedMsg).get(), ToString(kFoundCharMsg).get()));
-          // Cancel to crash, but we need to check the removed message value.
-          doCrash = false;
-        }
+      // If there is still existing a char message caused by same physical key
+      // in the queue but PeekMessage(PM_REMOVE) failed to remove it from the
+      // queue, it might be possible that the odd keyboard layout or utility
+      // hooks only PeekMessage(PM_NOREMOVE) and GetMessage().  So, let's try
+      // remove the char message with GetMessage() again.
+      // FYI: The wParam might be different from the found message, but it's
+      //      okay because we assume that odd keyboard layouts return actual
+      //      inputting character at removing the char message.
+      if (WinUtils::GetMessage(&removedMsg, mMsg.hwnd,
+                               nextKeyMsg.message, nextKeyMsg.message)) {
+        MOZ_LOG(sNativeKeyLogger, LogLevel::Warning,
+          ("%p   NativeKey::GetFollowingCharMessage(), WARNING, failed to "
+           "remove a char message, but succeeded with GetMessage(), "
+           "removedMsg=%s, kFoundCharMsg=%s",
+           this, ToString(removedMsg).get(), ToString(kFoundCharMsg).get()));
+        // Cancel to crash, but we need to check the removed message value.
+        doCrash = false;
       }
       // If we've already removed some WM_NULL messages from the queue and
       // the found message has already gone from the queue, let's treat the key