Adds the ability for the renderer to create the mojo channel

content/renderer/render_thread_impl.cc

Index: content/renderer/render_thread_impl.cc
diff --git a/content/renderer/render_thread_impl.cc b/content/renderer/render_thread_impl.cc
index 689fd8d125300ea38275b38b9328aa4e09df74e2..81e052c47273c654fad699c4d872d747d141d668 100644
--- a/content/renderer/render_thread_impl.cc
+++ b/content/renderer/render_thread_impl.cc
@@ -146,6 +146,11 @@
 #include "content/renderer/npapi/plugin_channel_host.h"
 #endif
 
+// TODO(sky): remove ifdef, temporary until mac/android sorted out.
+#if !defined(OS_MACOSX) && !defined(OS_ANDROID)
+#include "content/renderer/mojo_message_filter.h"
+#endif
+
 using base::ThreadRestrictions;
 using blink::WebDocument;
 using blink::WebFrame;
@@ -386,6 +391,12 @@ void RenderThreadImpl::Init() {
 
   AddFilter((new EmbeddedWorkerContextMessageFilter())->GetFilter());
 
+// TODO(sky): remove ifdef, temporary until mac/android sorted out.
+#if !defined(OS_MACOSX) && !defined(OS_ANDROID)
+  // MojoMessageFilter deletes itself as necessary.

[Tom Sepez, 2014/03/13 23:05:36]

nit: can we avoid this pattern and use AddFilter instead?  It looks wrong
despite the comment. 

[sky, 2014/03/13 23:10:50]

I actually did this first, then pulled out my hair trying to figure out why
MojoMessageFilter wasn't getting the message. Turns out this happens because the
message is a control message (it isn't associated with a particular view) and
control messages don't go to the filters.

MojoMessageFilter is a bit confusingly named since it's a
RenderProcessHostObserver and not a filter, but I couldn't think of a better
name.

+  new MojoMessageFilter(this);
+#endif
+
   GetContentClient()->renderer()->RenderThreadStarted();
 
   InitSkiaEventTracer();