Get mus_ws_unittests working with Ozone X11.

services/ui/ws/window_manager_client_unittest.cc

Index: services/ui/ws/window_manager_client_unittest.cc
diff --git a/services/ui/ws/window_manager_client_unittest.cc b/services/ui/ws/window_manager_client_unittest.cc
index 6362f4cc782fe8491f1766199e99935b1e6e0335..d1c370b9c7fade266b2ccfd6fe341d7b75e58d5b 100644
--- a/services/ui/ws/window_manager_client_unittest.cc
+++ b/services/ui/ws/window_manager_client_unittest.cc
@@ -353,6 +353,14 @@ class WindowServerTest : public WindowServerTestBase {
       EXPECT_TRUE(WindowServerTestBase::QuitRunLoop());
   }
 
+#if defined(USE_OZONE)
+  // mojo::test::ServiceTest::
+  std::unique_ptr<base::MessageLoop> CreateMessageLoop() override {
+    // TYPE_UI is needed for platform events coming from libevent.

[sky, 2017/02/02 16:27:05]

Is there any harm in doing this every where, not just ozone?

[rjkroege, 2017/02/02 16:38:42]

There is a possibility of increased flake (see discussion in
https://codereview.chromium.org/2629983002/) if we use it when not necessary.

I have a different nit (that could be addressed with a TODO) that when we should
be so lucky as to have DRM or Wayland builders, this code will needlessly use a
UI message loop yes?


 

[kylechar, 2017/02/02 18:01:29]

rjkroege: Confusingly, this is actually something different. These tests are for
parts of mus-ws process, which is always TYPE_UI (even for Ozone DRM). The Ozone
MessageLoop type stuff we've been discussing is for the GPU process, which only
needs TYPE_UI when running X11.

sky: There shouldn't be any harm in having this always be TYPE_UI. In fact, the
code needs to be able to run with TYPE_UI, so it's probably better? Changed.

+    return base::MakeUnique<base::MessageLoop>(base::MessageLoop::TYPE_UI);
+  }
+#endif
+
   std::unique_ptr<EmbedDetails> embed_details_;
 
   std::unique_ptr<ClientAreaChange> client_area_change_;