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
authorMasayuki Nakano <masayuki@d-toybox.com>
Fri, 03 Feb 2017 18:01:33 +0900
changeset 340875 3504f8cdd850178af9a2f2a5a1361a8e347a87e6
parent 340874 448a2d9d62c2951f6da51cd9ff5aa96ac88c67e8
child 340876 401683745308733d1ec980b6ba4cab53c7f38bd5
push id31317
push usercbook@mozilla.com
push dateMon, 06 Feb 2017 11:55:02 +0000
treeherdermozilla-central@c5621cb6f907 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersm_kato
bugs1336331, 1336322
milestone54.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
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
widget/windows/KeyboardLayout.cpp
--- a/widget/windows/KeyboardLayout.cpp
+++ b/widget/windows/KeyboardLayout.cpp
@@ -2970,31 +2970,33 @@ NativeKey::GetFollowingCharMessage(MSG& 
            "remove a char message due to message change, let's retry to "
            "remove the message with newly found char message, ",
            "nextKeyMsgInAllWindows=%s, nextKeyMsg=%s, kFoundCharMsg=%s",
            this, ToString(nextKeyMsgInAllWindows).get(),
            ToString(nextKeyMsg).get(), ToString(kFoundCharMsg).get()));
         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
       // as inputting no characters and already consumed.
       else if (i > 0) {
         MOZ_LOG(sNativeKeyLogger, LogLevel::Warning,
           ("%p   NativeKey::GetFollowingCharMessage(), WARNING, failed to "
            "remove a char message, but removed %d WM_NULL messages",