Service CreateNewWindow on the UI thread with a new mojo interface

content/renderer/render_thread_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/render_thread_impl.h"
 
 #include <algorithm>
 #include <limits>
 #include <map>
 #include <utility>
@@ skipping 519 matching lines @@
 
 // static
 mojom::RenderMessageFilter* RenderThreadImpl::current_render_message_filter() {
   if (g_render_message_filter_for_testing)
     return g_render_message_filter_for_testing;
   DCHECK(current());
   return current()->render_message_filter();
 }
 
 // static
+mojom::RenderMessageFilterUI*
+RenderThreadImpl::current_render_message_filter_ui() {
+  DCHECK(current());
+  return current()->render_message_filter_ui();
+}
+
+// static
 void RenderThreadImpl::SetRenderMessageFilterForTesting(
     mojom::RenderMessageFilter* render_message_filter) {
   g_render_message_filter_for_testing = render_message_filter;
 }
 
 // In single-process mode used for debugging, we don't pass a renderer client
 // ID via command line because RenderThreadImpl lives in the same process as
 // the browser
 RenderThreadImpl::RenderThreadImpl(
     const InProcessChildThreadParams& params,
@@ skipping 1498 matching lines @@
     GetChannel()->GetRemoteAssociatedInterface(&render_frame_message_filter_);
   return render_frame_message_filter_.get();
 }
 
 mojom::RenderMessageFilter* RenderThreadImpl::render_message_filter() {
   if (!render_message_filter_)
     GetChannel()->GetRemoteAssociatedInterface(&render_message_filter_);
   return render_message_filter_.get();
 }
 
+mojom::RenderMessageFilterUI* RenderThreadImpl::render_message_filter_ui() {
+  if (!render_message_filter_ui_) {
+    blink_platform_impl_->GetInterfaceProvider()->GetInterface(

[Charlie Harrison, 2017/04/13 19:27:58]

This is weird and wrong. Probably should just use the connector directly?

[dcheng, 2017/04/13 21:00:14]

Maybe this should be an associated interface to keep the same behavior?

[Charlie Harrison, 2017/04/13 21:48:12]

Hm... How would that work? Isn't it fundamentally against the spirit of an
associated interface (same underlying pipe) for endpoints to be on two different
threads?

+        mojo::MakeRequest(&render_message_filter_ui_));
+  }
+
+  return render_message_filter_ui_.get();
+}
+
 gpu::GpuChannelHost* RenderThreadImpl::GetGpuChannel() {
   if (!gpu_channel_)
     return nullptr;
   if (gpu_channel_->IsLost())
     return nullptr;
   return gpu_channel_.get();
 }
 
 void RenderThreadImpl::OnFieldTrialGroupFinalized(
     const std::string& trial_name,
@@ skipping 381 matching lines @@
   }
 }
 
 void RenderThreadImpl::OnRendererInterfaceRequest(
     mojom::RendererAssociatedRequest request) {
   DCHECK(!renderer_binding_.is_bound());
   renderer_binding_.Bind(std::move(request));
 }
 
 }  // namespace content