Adds support for headless chrome embedder mojo services

headless/lib/browser/headless_web_contents_impl.cc

 // Copyright 2015 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 "headless/lib/browser/headless_web_contents_impl.h"
 
 #include "base/bind.h"
+#include "base/json/json_writer.h"
 #include "base/memory/ptr_util.h"
 #include "base/memory/weak_ptr.h"
+#include "base/strings/utf_string_conversions.h"
 #include "base/trace_event/trace_event.h"
 #include "content/public/browser/devtools_agent_host.h"
 #include "content/public/browser/navigation_handle.h"
 #include "content/public/browser/render_frame_host.h"
 #include "content/public/browser/render_process_host.h"
 #include "content/public/browser/render_view_host.h"
 #include "content/public/browser/render_widget_host_view.h"
 #include "content/public/browser/web_contents.h"
 #include "content/public/browser/web_contents_delegate.h"
-#include "content/public/browser/web_contents_observer.h"
 #include "content/public/common/bindings_policy.h"
 #include "content/public/common/service_registry.h"
 #include "content/public/renderer/render_frame.h"
 #include "headless/lib/browser/headless_browser_context_impl.h"
 #include "headless/lib/browser/headless_browser_impl.h"
 #include "headless/lib/browser/headless_browser_main_parts.h"
 #include "headless/lib/browser/headless_devtools_client_impl.h"
 #include "ui/aura/window.h"
 
 namespace headless {
@@ skipping 42 matching lines @@
     HeadlessBrowserImpl* browser) {
   content::BrowserContext* context =
       HeadlessBrowserContextImpl::From(builder->browser_context_);
   content::WebContents::CreateParams create_params(context, nullptr);
   create_params.initial_size = builder->window_size_;
 
   std::unique_ptr<HeadlessWebContentsImpl> headless_web_contents =
       base::WrapUnique(new HeadlessWebContentsImpl(
           content::WebContents::Create(create_params), browser));
 
+  headless_web_contents->InstallMojoServices(
+      std::move(builder->mojo_services_));
+  headless_web_contents->InstallMojoBindings(
+      std::move(builder->mojo_bindings_));
   headless_web_contents->InitializeScreen(parent_window, builder->window_size_);
   if (!headless_web_contents->OpenURL(builder->initial_url_))
     return nullptr;
   return headless_web_contents;
 }
 
 // static
 std::unique_ptr<HeadlessWebContentsImpl>
 HeadlessWebContentsImpl::CreateFromWebContents(
     content::WebContents* web_contents,
@@ skipping 11 matching lines @@
   parent_window->AddChild(contents);
   contents->Show();
 
   contents->SetBounds(gfx::Rect(initial_size));
   content::RenderWidgetHostView* host_view =
       web_contents_->GetRenderWidgetHostView();
   if (host_view)
     host_view->SetSize(initial_size);
 }
 
+void HeadlessWebContentsImpl::InstallMojoServices(
+    std::list<MojoService> mojo_services) {
+  if (mojo_services.empty())
+    return;
+
+  content::ServiceRegistry* service_registry =
+      web_contents_->GetRenderViewHost()->GetMainFrame()->GetServiceRegistry();
+
+  for (const MojoService& service : mojo_services) {
+    service_registry->AddService(service.service_name,
+                                 std::move(service.service_factory),
+                                 browser_->BrowserMainThread());
+  }
+}
+
+void HeadlessWebContentsImpl::InstallMojoBindings(
+    std::list<MojoBindings> mojo_bindings) {
+  mojo_bindings_ = std::move(mojo_bindings);
+
+  if (mojo_bindings_.empty())
+    return;
+
+  web_contents_->GetRenderViewHost()->AllowBindings(
+      content::BINDINGS_POLICY_MOJO);

[Charlie Reis, 2016/06/21 18:23:49]

This seems like a problem.  If you do a cross-process navigation in this
WebContents, it looks like the new RenderViewHost won't get these bindings. 
Same if you go back after a cross-process navigation, in which case the NavEntry
will remember that you had bindings before (and notice that you don't the second
time) and cause a SetBindings crash.

[alex clarke (OOO till 29th), 2016/06/21 19:52:44]

Is there a better way of installing them?

It's hard to predict everything people will use this for, I hadn't even
considered somebody might want to navigate a webcontents after the bindings have
been set.  Obviously that's possible so we need to fix it :)

[Charlie Reis, 2016/06/21 20:05:48]

WebContentsObserver::RenderFrameCreated is a better way to watch for it. 
There's an example in BlinkTestController, which calls HandleNewRenderFrameHost
to allow the bindings.

(Side note: that class also listens to RenderFrameHostChanged, but I have a
suspicion that's redundant with RenderFrameCreated.)

While looking that up, I also remembered that
RenderFrameImpl::MaybeEnableMojoBindings() is likely to cause problems for you. 
It makes the assumption that BIDNINGS_POLICY_MOJO is only used for layout tests
and tells MojoBindingsController (which appears to affect MojoContextState).  I
brought that up as a concern when reviewing
https://codereview.chromium.org/1707233003, but apparently it's still
implemented that way.  It looks like the code assumes that bindings for WebUI
and the MOJO bindings (for layout tests) are mutually exclusive, but that's
probably no longer true for your case.

You might want to check with sammc about what the implications are there.

[alex clarke (OOO till 29th), 2016/06/21 20:39:23]

OK. I'll have a go at using that and write a browser test.
Yes I had to use the mojo.define => define shim which adds complexity.

 I
I did try implementing this in terms of WebUI bindings but that seems to have
implications that seemed scary requiring privileged views.   Also doing so
exposes the UI mojo modules which isn't something we need and might cause
problems (we wouldn't want somebody to rely on them if the API isn't stable).

[alex clarke (OOO till 29th), 2016/06/21 21:56:34]

Done.

[Charlie Reis, 2016/06/21 23:08:31]

I don't know what this means.  Won't you still hit
RenderFrameImpl::MaybeEnableMojoBindings via RenderFrameImpl::Initialize, and
thus tell MojoContextState that it's for_layout_tests, setting the
module_prefix_ to layout-test-mojom://?

I don't know a lot about Mojo, but that sounds problematic to me.  sammc@, can
you confirm?
Agreed, WebUI is definitely not a safe way to implement anything visiting real
web pages.

[Sam McNally, 2016/06/22 01:09:11]

Yes, BINDINGS_POLICY_MOJO is only suitable for layout tests. Fixing/replacing
the current JS mojo bindings has been on our todo list for a while but the
current house of cards hasn't caught fire and fallen over yet so it's been
fairly low priority so far.

[alex clarke (OOO till 29th), 2016/06/22 10:04:00]

Right.  That actually isn't a problem for us since we deliberately push the
bindings from browser to renderer.  I did try the pull method in an earlier
patch set but we where worried about letting the renderer request potentially
arbitrary files from disc.

One consequence of BINDINGS_POLICY_MOJO is the define api is called mojo.define
and we need a shim (copied from the layout test helpers) to map define() =>
mojo.define().  It would be nice if we didn't have to do that.

[alex clarke (OOO till 29th), 2016/06/22 10:04:00]

Agreed that BINDINGS_POLICY_MOJO doesn't quite fit the needs of headless.  What
I (think) we need for headless is:

* Browser pushes js bindings (we think that's safer)
* The define() interface is added instead of mojo.define()
* Don't need a privileged view

What I think we should do is land this patch (that will unblock some fairly high
priority internal work), and decide how best to support this new use case.  Once
that's sorted out I'll be happy to change headless to use the new way.  I don't
mind implementing the new way although I don't fully understand the other use
cases.

[Charlie Reis, 2016/06/22 19:30:59]

Sorry, I don't know what you're referring to with push vs pull.  If
RenderFrameImpl::MaybeEnableMojoBindings() thinks you have BINDING_POLICY_MOJO,
then you're likely to have problems.

Are you saying that RenderProcess::current()->GetEnabledBindings() won't return
BINDINGS_POLICY_MOJO in your case, so MaybeEnableMojoBindings() won't create a
MojoBindingsController?
I'll have to defer the "define" stuff to others who know more about Mojo.
I don't see how this is safe to land yet, but maybe your answer to my
MaybeEnableMojoBindings() question above will resolve it.  (Happy to defer to
sammc@ if he thinks it's safe.)

[alex clarke (OOO till 29th), 2016/06/22 20:54:22]

Happy to set up a VC if that would help. But I'll try and explain here :)  

There are two classes of js mojo bindings:

1. Special built in ones installed by
RenderFrame::EnsureMojoBuiltinsAreAvailable. 
2. General .mojom bindings.  Normally are fetched on demand by
MojoContextState::FetchModule and then the js is evaluated. I've been calling
this the 'pull method'.

Sami doesn't think #2 is safe in the context of headless, the problem being the
renderer is asking to browser to load an arbitrary file. For layout tests this
is loading is done by MojomProtocolHandler in layout_test_browser_context.cc,
we'd probably need something similar for headless.

For headless we know what modules the user wishes to install and can 'push' them
to the renderer by using RenderFrameHost::ExecuteJavaScriptForTests to eval the
binding js (see HeadlessWebContentsImpl::DocumentOnLoadCompletedInMainFrame
below).   Thus it's fine if MaybeEnableMojoBindings is called. We don't care if
the module_prefix_ is layout-test-mojom:// the reason being since we supply the
binding MojoContextState::FetchModule never gets called so the prefix isn't
used.

One problem with our approach is JS on the page might run before the browser has
had a chance to push the bindings to the renderer.  Our convenience bindings
installed by HeadlessContentRendererClient::RunScriptsAtDocumentStart work
around that with promises and ES6 proxy class trickery. 
HeadScriptEmbedderMojoBindingsTest is there to test that is working.

There is one complication we have to work around with BINDING_POLICY_MOJO. The
MojoContextState constructor creates a mojo.define gin binding instead of a
define binding.  This is a problem because the mojom js bindings assume that
define() is used so we some js to implement define() in terms of mojo.define().

I'd like not to have to do that :)

[Charlie Reis, 2016/06/22 23:18:48]

Maybe a VC would be useful, or I could defer to someone who knows this better. 
(I'm sick/WFH today, though.)
  
This is a problem in itself.  I've left a comment about the use of
ExecuteJavaScriptForTests, which is not allowed.
I clearly don't understand enough of this to approve it as safe.  It seems to me
like the layout test situation with BINDING_POLICY_MOJO is setting up a bunch of
landmines that you might be dodging now but could hit later.

+}
+
 HeadlessWebContentsImpl::HeadlessWebContentsImpl(
     content::WebContents* web_contents,
     HeadlessBrowserImpl* browser)
-    : web_contents_delegate_(new HeadlessWebContentsImpl::Delegate(browser)),
+    : content::WebContentsObserver(web_contents),
+      web_contents_delegate_(new HeadlessWebContentsImpl::Delegate(browser)),
       web_contents_(web_contents),
       browser_(browser) {
   web_contents_->SetDelegate(web_contents_delegate_.get());
 }
 
 HeadlessWebContentsImpl::~HeadlessWebContentsImpl() {
   web_contents_->Close();
 }
 
+void HeadlessWebContentsImpl::DocumentOnLoadCompletedInMainFrame() {
+  // Install mojo bindings by executing the bindings js.  Note this has to be
+  // done here since this is the earliest callback the browser has after the
+  // mojo module service is created at document start.
+  content::RenderFrameHost* render_frame_host = web_contents_->GetMainFrame();
+  base::ListValue module_list;
+  for (const MojoBindings& binding : mojo_bindings_) {
+    // Note RenderFrameHostImpl is unaware of headless chrome and we have to
+    // work around it's limits on when it's safe to call JS by using the
+    // ForTests version.
+    // TODO(alexclarke): Consider fixing this.
+    render_frame_host->ExecuteJavaScriptForTests(
+        base::UTF8ToUTF16(binding.js_bindings));
+    module_list.AppendString(binding.mojom_name);
+  }
+  std::string json_module_list;
+  CHECK(base::JSONWriter::Write(module_list, &json_module_list));
+  render_frame_host->ExecuteJavaScriptForTests(base::UTF8ToUTF16(
+      "mojo.resolvePromisesForServices_(" + json_module_list + ");"));
+}
+
 bool HeadlessWebContentsImpl::OpenURL(const GURL& url) {
   if (!url.is_valid())
     return false;
   content::NavigationController::LoadURLParams params(url);
   params.transition_type = ui::PageTransitionFromInt(
       ui::PAGE_TRANSITION_TYPED | ui::PAGE_TRANSITION_FROM_ADDRESS_BAR);
   web_contents_->GetController().LoadURLWithParams(params);
   web_contents_->Focus();
   return true;
 }
@@ skipping 53 matching lines @@
   window_size_ = size;
   return *this;
 }
 
 HeadlessWebContents::Builder& HeadlessWebContents::Builder::SetBrowserContext(
     HeadlessBrowserContext* browser_context) {
   browser_context_ = browser_context;
   return *this;
 }
 
+HeadlessWebContents::Builder& HeadlessWebContents::Builder::AddMojoService(
+    const std::string& service_name,
+    const base::Callback<void(mojo::ScopedMessagePipeHandle)>&
+        service_factory) {
+  mojo_services_.emplace_back(service_name, service_factory);
+  return *this;
+}
+
+HeadlessWebContents::Builder& HeadlessWebContents::Builder::AddJsMojoBindings(
+    const std::string& mojom_name,
+    const std::string& js_bindings) {
+  mojo_bindings_.emplace_back(mojom_name, js_bindings);
+  return *this;
+}
+
 HeadlessWebContents* HeadlessWebContents::Builder::Build() {
   return browser_->CreateWebContents(this);
 }
 
+HeadlessWebContents::Builder::MojoService::MojoService() {}
+
+HeadlessWebContents::Builder::MojoService::MojoService(
+    const std::string& service_name,
+    const base::Callback<void(mojo::ScopedMessagePipeHandle)>& service_factory)
+    : service_name(service_name), service_factory(service_factory) {}
+
+HeadlessWebContents::Builder::MojoService::~MojoService() {}
+
+HeadlessWebContents::Builder::MojoBindings::MojoBindings() {}
+
+HeadlessWebContents::Builder::MojoBindings::MojoBindings(
+    const std::string& mojom_name,
+    const std::string& js_bindings)
+    : mojom_name(mojom_name), js_bindings(js_bindings) {}
+
+HeadlessWebContents::Builder::MojoBindings::~MojoBindings() {}
+
 }  // namespace headless