Bug 1343446 NativeKey::GetFollowingCharMessage() should ignore found message if PeekMessage(PM_REMOVE) retrieves different char message but the found odd char message was odd r=m_kato
authorMasayuki Nakano <masayuki@d-toybox.com>
Wed, 01 Mar 2017 14:48:05 +0900
changeset 394537 c3563703a34d21d9442654503b15a97795868e42
parent 394536 f7488b81a40a5ab1322ce6a2da4fa032dfabff6a
child 394538 87176aa9560af31faf448464e28b7c53a459f9af
push id1468
push userasasaki@mozilla.com
push dateMon, 05 Jun 2017 19:31:07 +0000
treeherdermozilla-release@0641fc6ee9d1 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersm_kato
bugs1343446
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 1343446 NativeKey::GetFollowingCharMessage() should ignore found message if PeekMessage(PM_REMOVE) retrieves different char message but the found odd char message was odd r=m_kato According to crash reports, we may find WM_CHAR whose wParam is 0 and scancode is 0xFF with a call of PeekMessage(PM_NOREMOVE) but we'll remove usual char message with a call of PeekMessage(PM_REMOVE). In such case, we should ignore the found odd message and take the usual char message which was removed from the queue actually. MozReview-Commit-ID: Gw8LvCXxul
widget/windows/KeyboardLayout.cpp
--- a/widget/windows/KeyboardLayout.cpp
+++ b/widget/windows/KeyboardLayout.cpp
@@ -3126,16 +3126,33 @@ NativeKey::GetFollowingCharMessage(MSG& 
          "remove a char message, but the removed message was changed from "
          "the found message except their scancode, aCharMsg=%s, "
          "nextKeyMsg=%s, kFoundCharMsg=%s",
          this, ToString(aCharMsg).get(), ToString(nextKeyMsg).get(),
          ToString(kFoundCharMsg).get()));
       return true;
     }
 
+    // When found message's wParam is 0 and its scancode is 0xFF, we may remove
+    // usual char message actually.  In such case, we should use the removed
+    // char message.
+    if (IsCharMessage(removedMsg) && !nextKeyMsg.wParam &&
+        WinUtils::GetScanCode(nextKeyMsg.lParam) == 0xFF) {
+      aCharMsg = removedMsg;
+      MOZ_LOG(sNativeKeyLogger, LogLevel::Warning,
+        ("%p   NativeKey::GetFollowingCharMessage(), WARNING, succeeded to "
+         "remove a char message, but the removed message was changed from "
+         "the found message but the found message was odd, so, ignoring the "
+         "odd found message and respecting the removed message, aCharMsg=%s, "
+         "nextKeyMsg=%s, kFoundCharMsg=%s",
+         this, ToString(aCharMsg).get(), ToString(nextKeyMsg).get(),
+         ToString(kFoundCharMsg).get()));
+      return true;
+    }
+
     // NOTE: Although, we don't know when this case occurs, the scan code value
     //       in lParam may be changed from 0 to something.  The changed value
     //       is different from the scan code of handling keydown message.
     MOZ_LOG(sNativeKeyLogger, LogLevel::Error,
       ("%p   NativeKey::GetFollowingCharMessage(), FAILED, removed message "
        "is really different from what we have already found, removedMsg=%s, "
        "nextKeyMsg=%s, kFoundCharMsg=%s",
        this, ToString(removedMsg).get(), ToString(nextKeyMsg).get(),