Revert "Fix Windows touchpad lagging in first tab"

This reverts commit 12dca865.

Reason for revert: crbug.com/795223

Original change's description:
> 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}

TBR=thestig@chromium.org,brucedawson@chromium.org,chaopeng@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 713907, 596190, 795223
Change-Id: I3f53fd77e7a6545cd214444cac46709cff0142c9
Reviewed-on: https://chromium-review.googlesource.com/830174
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Reviewed-by: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524428}

base/message_loop/message_pump_win.cc

@@ -202,13 +202,46 @@ 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 = GetCurrentDelay();
-  if (delay < 0)  // Negative value means no timers waiting.
-    delay = INFINITE;
-  DWORD result = MsgWaitForMultipleObjectsEx(0, nullptr, delay, QS_ALLINPUT,
-                                             MWMO_INPUTAVAILABLE);
+  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;
+    }
 
-  DCHECK_NE(WAIT_FAILED, result) << GetLastError();
+    DCHECK_NE(WAIT_FAILED, result) << GetLastError();
+  }
 }
 
 void MessagePumpForUI::HandleWorkMessage() {