Bug 1300003 part.3 NativeKey::GetFollowingCharMessage() should always remove following WM_CHAR message r=m_kato

GetFollowingCharMessage() is now called only when removing following char message.  Therefore, it does not need to have the optional argument indicating if removing the found message.

MozReview-Commit-ID: 7P39wyfSC1

--HG--
extra : rebase_source : a38bb961df1bc03adc21295bc39e4e9c16e864f2

widget/windows/KeyboardLayout.cpp

@@ -2134,7 +2134,7 @@ NativeKey::MayBeSameCharMessage(const MSG& aCharMsg1,
 }
 
 bool
-NativeKey::GetFollowingCharMessage(MSG& aCharMsg, bool aRemove) const
+NativeKey::GetFollowingCharMessage(MSG& aCharMsg) const
 {
   MOZ_ASSERT(IsKeyDownMessage());
   MOZ_ASSERT(!IsKeyMessageOnPlugin());
@@ -2148,7 +2148,7 @@ NativeKey::GetFollowingCharMessage(MSG& aCharMsg, bool aRemove) const
         continue;
       }
       MSG charMsg = fakeCharMsg.GetCharMsg(mMsg.hwnd);
-      fakeCharMsg.mConsumed = aRemove;
+      fakeCharMsg.mConsumed = true;
       if (!IsCharMessage(charMsg)) {
         return false;
       }
@@ -2170,11 +2170,6 @@ NativeKey::GetFollowingCharMessage(MSG& aCharMsg, bool aRemove) const
     return false;
   }
 
-  if (!aRemove) {
-    aCharMsg = nextKeyMsg;
-    return true;
-  }
-
   // On Metrofox, PeekMessage() sometimes returns WM_NULL even if we specify
   // the message range.  So, if it returns WM_NULL, we should retry to get
   // the following char message it was found above.

widget/windows/KeyboardLayout.h

@@ -447,11 +447,8 @@ private:
    *
    * WARNING: Even if this returns true, aCharMsg may be WM_NULL or its
    *          hwnd may be different window.
-   *
-   * @param aRemove     true if the found message should be removed from the
-   *                    queue.  Otherwise, false.
    */
-  bool GetFollowingCharMessage(MSG& aCharMsg, bool aRemove = true) const;
+  bool GetFollowingCharMessage(MSG& aCharMsg) const;
 
   /**
    * Whether the key event can compute virtual keycode from the scancode value.