Expose mojo bindings to subframes in layout tests.

content/renderer/render_frame_impl.cc

 // Copyright 2013 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_frame_impl.h"
 
 #include <map>
 #include <string>
 #include <utility>
 #include <vector>
@@ skipping 1094 matching lines @@
   if (is_tracing) {
     int parent_id = GetRoutingIdForFrameOrProxy(frame_->parent());
     TRACE_EVENT2("navigation", "RenderFrameImpl::Initialize",
                  "id", routing_id_,
                  "parent", parent_id);
   }
 
   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)
   new PepperBrowserConnection(this);
 #endif
   new SharedWorkerRepository(this);
 
   if (IsLocalRoot() && !is_swapped_out_) {
     // DevToolsAgent is a RenderFrameObserver, and will destruct itself
     // when |this| is deleted.
@@ skipping 4977 matching lines @@
                                     int match_count,
                                     int ordinal,
                                     const WebRect& selection_rect,
                                     bool final_status_update) {
   Send(new FrameHostMsg_Find_Reply(routing_id_, request_id, match_count,
                                    selection_rect, ordinal,
                                    final_status_update));
 }
 
 }  // namespace content