Use MessagePumpForUIQt for UI thread only

In what almost seems like intentionally confusing terminology, Chromium draws a
distinction between the UI thread and UI type threads. The thread's type refers
mainly to the MessagePump implementation that it uses: currently
MessagePumpForUIQt for all UI type threads.

It turns out however that the desktop capture thread on macOS requires the
original MessagePumpMac implementation for some macOS specifics. So, with this
patch, MessagePumpForUIQt will be used only for the actual UI thread, and all
other UI type threads will use upstream message pump implementations.

Theoretically, this means that we cannot send events or async signals to these
other UI type threads any more (sending events *from* these threads should still
work). Practically though it seems safer to try, as far as possible, to not mix
different event/task frameworks on the same thread.

Change-Id: I81308d62c64354230796fccce2d3e0fa6cbb5013
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>

1 files changed, 2 insertions, 3 deletions

diff --git a/src/core/browser_main_parts_qt.h b/src/core/browser_main_parts_qt.h
index 374220c3b..4eb10e379 100644
--- a/src/core/browser_main_parts_qt.h
+++ b/src/core/browser_main_parts_qt.h
@@ -43,7 +43,7 @@
 #include "content/public/browser/browser_main_parts.h"
 
 namespace base {
-class MessagePump;
+class MessageLoop;
 }
 
 namespace content {
@@ -56,8 +56,6 @@ class ProcessResourceCoordinator;
 
 namespace QtWebEngineCore {
 
-std::unique_ptr<base::MessagePump> messagePumpFactory();
-
 class BrowserMainPartsQt : public content::BrowserMainParts
 {
 public:
@@ -74,6 +72,7 @@ public:
 private:
     DISALLOW_COPY_AND_ASSIGN(BrowserMainPartsQt);
     std::unique_ptr<resource_coordinator::ProcessResourceCoordinator> m_processResourceCoordinator;
+    std::unique_ptr<base::MessageLoop> m_mainMessageLoop;
 };
 
 } // namespace QtWebEngineCore