Fix Windows touchpad lagging in first tab

Currently the receiving of WM_MOUSEWHEEL messages lags when we open a
URL on a new window until we resize. The issue was introduced by
r384698. That CL change wait for MOUSE_EVENT to wait for SENDMESSAGE
in MessagePumpForUI::WaitForWork to optimize the GPU thread. But the
GPU thread does not use MessagePumpForUI anymore so it should be OK to
just remove that code.

The updated version of Chrome was tested to make sure that the hangs
that were occasionally seen when using chrome://tracing are still gone.

After this CL chaopeng@ need to monitor to make sure that the crash
rate not increase.

Bug: 713907, 596190
Change-Id: I7545a867de4851acd4e57c9b8c7a3dd05def1dd8
Reviewed-on: https://chromium-review.googlesource.com/809829
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523689}

base/message_loop/message_pump_win.cc

@@ -202,46 +202,13 @@ void MessagePumpForUI::DoRunLoop() {
 void MessagePumpForUI::WaitForWork() {
   // Wait until a message is available, up to the time needed by the timer
   // manager to fire the next set of timers.
-  int delay;
-  DWORD wait_flags = MWMO_INPUTAVAILABLE;
-
-  while ((delay = GetCurrentDelay()) != 0) {
-    if (delay < 0)  // Negative value means no timers waiting.
-      delay = INFINITE;
-
-    DWORD result = MsgWaitForMultipleObjectsEx(0, nullptr, delay, QS_ALLINPUT,
-                                               wait_flags);
-
-    if (WAIT_OBJECT_0 == result) {
-      // A WM_* message is available.
-      // If a parent child relationship exists between windows across threads
-      // then their thread inputs are implicitly attached.
-      // This causes the MsgWaitForMultipleObjectsEx API to return indicating
-      // that messages are ready for processing (Specifically, mouse messages
-      // intended for the child window may appear if the child window has
-      // capture).
-      // The subsequent PeekMessages call may fail to return any messages thus
-      // causing us to enter a tight loop at times.
-      // The code below is a workaround to give the child window
-      // some time to process its input messages by looping back to
-      // MsgWaitForMultipleObjectsEx above when there are no messages for the
-      // current thread.
-      MSG msg = {0};
-      bool has_pending_sent_message =
-          (HIWORD(GetQueueStatus(QS_SENDMESSAGE)) & QS_SENDMESSAGE) != 0;
-      if (has_pending_sent_message ||
-          PeekMessage(&msg, nullptr, 0, 0, PM_NOREMOVE)) {
-        return;
-      }
-
-      // We know there are no more messages for this thread because PeekMessage
-      // has returned false. Reset |wait_flags| so that we wait for a *new*
-      // message.
-      wait_flags = 0;
-    }
+  int delay = GetCurrentDelay();
+  if (delay < 0)  // Negative value means no timers waiting.
+    delay = INFINITE;
+  DWORD result = MsgWaitForMultipleObjectsEx(0, nullptr, delay, QS_ALLINPUT,
+                                             MWMO_INPUTAVAILABLE);
 
-    DCHECK_NE(WAIT_FAILED, result) << GetLastError();
-  }
+  DCHECK_NE(WAIT_FAILED, result) << GetLastError();
 }
 
 void MessagePumpForUI::HandleWorkMessage() {