Bug 1790160 - In MessagePumpForUI for Windows, effectively apply upstream's...

Bug 1790160 - In MessagePumpForUI for Windows, effectively apply upstream's commit b26918c. r=mossop,ipc-reviewers,gfx-reviewers,nika,nical a=RyanVM

As MessagePumpForUI is an old fork from Chromium, this patch effectively applies
the Chromium patch
https://source.chromium.org/chromium/chromium/src/+/b26918c5ab0da3130b92339f44ebdc4bfee1b351

For those threads where we use MessagePumpForUI we already have a way of
stopping the thread and thereby quitting the message loop. At the same time some
applications may send us unexpected WM_QUIT messages on those threads. Generally
the code using the thread is not able to handle this gracefully and we end up
crashing.

In particular there is a correlation between these crashes and certain antivirus
applications.

Differential Revision: https://phabricator.services.mozilla.com/D166432

ipc/chromium/src/base/message_pump_win.cc

@@ -154,8 +154,7 @@ void MessagePumpForUI::PumpOutPendingPaintMessages() {
     MSG msg;
     if (!PeekMessage(&msg, NULL, 0, 0, PM_REMOVE | PM_QS_PAINT)) break;
     ProcessMessageHelper(msg);
-    if (state_->should_quit)  // Handle WM_QUIT.
-      break;
+    if (state_->should_quit) break;
   }
 }
 
@@ -306,11 +305,10 @@ bool MessagePumpForUI::ProcessNextWindowsMessage() {
 
 bool MessagePumpForUI::ProcessMessageHelper(const MSG& msg) {
   if (WM_QUIT == msg.message) {
-    // Repost the QUIT message so that it will be retrieved by the primary
-    // GetMessage() loop.
-    state_->should_quit = true;
-    PostQuitMessage(static_cast<int>(msg.wParam));
-    return false;
+    // WM_QUIT is the standard way to exit a GetMessage() loop. Our MessageLoop
+    // has its own quit mechanism, so WM_QUIT is unexpected and should be
+    // ignored.
+    return true;
   }
 
   // While running our main message pump, we discard kMsgHaveWork messages.