Expose mojo bindings to subframes in layout tests.

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index 4549db8fc745140dfaaf4e8307da3aa80b067405..eab1b5c502fb531aad0a3f793e36cb6b91d830d0 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -1112,6 +1112,9 @@ void RenderFrameImpl::Initialize() {
   if (IsMainFrame() &&
       RenderProcess::current()->GetEnabledBindings() & BINDINGS_POLICY_WEB_UI) {
     EnableMojoBindings(false /* for_layout_tests */);
+  } else if (RenderProcess::current()->GetEnabledBindings() &

[Charlie Reis, 2016/02/19 06:26:34]

This doesn't look like it does the right thing.

We'll call EnableMojoBindings(true) for the main frame if there aren't WEB_UI
bindings and there are MOJO bindings.  That itself has subtle behavior because
it might not take effect if we already called EnableMojoBindings(false) in
RenderViewImpl.

We should be able to write this more cleanly.

[Sam McNally, 2016/02/22 09:31:19]

I don't think that's possible; RenderViewImpl will only call
EnableMojoBindings(false) if BINDINGS_POLICY_WEB_UI is enabled. It does feel
brittle spread across RenderViewImpl and RenderFrameImpl though.

+             BINDINGS_POLICY_MOJO) {
+    EnableMojoBindings(true /* for_layout_tests */);

[Charlie Reis, 2016/02/19 06:26:34]

I don't understand how to infer that it's for layout tests based on the absence
of WEB_UI bindings.  If another use of MOJO bindings were added (other than
WebUI and layout tests), wouldn't all the call sites of this become wrong?

[Sam McNally, 2016/02/22 09:31:19]

The way JS mojo bindings work in content is a bit strange:
BINDINGS_POLICY_WEB_UI enables mojo for WebUI; BINDINGS_POLICY_MOJO enables mojo
for layout tests. Enabling both at the same time won't work, but nothing tries
to do that.

If another use of mojo is added, or if the combination of BINDINGS_POLICY_WEB_UI
and BINDINGS_POLICY_MOJO starts being used, then this will be wrong, but the
same would be true of the similar code in RenderViewImpl::OnAllowBindings().

These two mojo uses each require a different strategy to load generated JS mojo
bindings (and extensions is doing its own thing for loading too), so adding a
new use is fairly non-trivial.

[esprehn, 2016/02/24 20:44:34]

There should be no process that contains v8 mojo bindings and doesn't include
blink. Blink provides idle callback handling, memory pressure, fast JS bindings,
and more. Using v8 without blink is not good, and the existing Gin bindings
really need to get migrated.

This callback out into the embedder that web UI is using is a hack, and should
be removed. Blink should have the low level mojo functions Send(), etc. in
actual blink idl files. Web UI should just include generated JS files using http
requests. This EnableMojoBindings thing needs to go away.

   }
 
 #if defined(ENABLE_PLUGINS)