Fix code blocks in mojo_in_chromium.md.

docs/mojo_in_chromium.md

 # Mojo in Chromium
 
 **THIS DOCUIMENT IS A WORK IN PROGRESS.** As long as this notice exists, you
 should probably ignore everything below it.
 
 This document is intended to serve as a Mojo primer for Chromium developers. No
 prior knowledge of Mojo is assumed, but you should have a decent grasp of C++
 and be familiar with Chromium's multi-process architecture as well as common
 concepts used throughout Chromium such as smart pointers, message loops,
 callback binding, and so on.
@@ skipping 136 matching lines @@
 
 `mojo::InterfacePtr<T>` is a typed proxy for a service of type `T`, which can be
 bound to a message pipe endpoint. This class implements every interface method
 on `T` by serializing a message (encoding the method call and its arguments) and
 writing it to the pipe (if bound.) This is the standard way for C++ code to talk
 to any Mojo service.
 
 For illustrative purposes only, we can create a message pipe and bind an
 `InterfacePtr` to one end as follows:
 
-```
+```cpp
   mojo::MessagePipe pipe;
   mojo::InterfacePtr<frob::Frobinator> frobinator;
   frobinator.Bind(
       mojo::InterfacePtrInfo<frob::Frobinator>(pipe.handle0.Pass(), 0u));
 ```
 
 You could then call `frobinator->Frobinate()` and read the encoded `Frobinate`
 message from the other side of the pipe (`handle1`.) You most likely don't want
 to do this though, because as you'll soon see there's a nicer way to establish
 service pipes.
 
 #### `mojo::InterfaceRequest<T>`
 
 Defined in `/third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h`.
 
 `mojo::InterfaceRequest<T>` is a typed container for a message pipe endpoint
 that should _eventually_ be bound to a service implementation. An
 `InterfaceRequest` doesn't actually _do_ anything, it's just a way of holding
 onto an endpoint without losing interface type information.
 
 A common usage pattern is to create a pipe, bind one end to an
 `InterfacePtr<T>`, and pass the other end off to someone else (say, over some
 other message pipe) who is expected to eventually bind it to a concrete service
 implementation. `InterfaceRequest<T>` is here for that purpose and is, as we'll
 see later, a first-class concept in Mojom interface definitions.
 
 As with `InterfacePtr<T>`, we can manually bind an `InterfaceRequest<T>` to a
 pipe endpoint:
 
-```
+```cpp
 mojo::MessagePipe pipe;
 
 mojo::InterfacePtr<frob::Frobinator> frobinator;
 frobinator.Bind(
     mojo::InterfacePtrInfo<frob::Frobinator>(pipe.handle0.Pass(), 0u));
 
 mojo::InterfaceRequest<frob::Frobinator> frobinator_request;
 frobinator_request.Bind(pipe.handle1.Pass());
 ```
 
 At this point we could start making calls to `frobinator->Frobinate()` as
 before, but they'll just sit in queue waiting for the request side to be bound.
 Note that the basic logic in the snippet above is such a common pattern that
 there's a convenient API function which does it for us.
 
 #### `mojo::GetProxy<T>`
 
 Defined in
 `/third_party/mojo/src/mojo/public/cpp/bindings/interface`_request.h`.
 
 `mojo::GetProxy<T>` is the function you will most commonly use to create a new
 message pipe. Its signature is as follows:
 
-```
+```cpp
 template <typename T>
 mojo::InterfaceRequest<T> GetProxy(mojo::InterfacePtr<T>* ptr);
 ```
 
 This function creates a new message pipe, binds one end to the given
 `InterfacePtr` argument, and binds the other end to a new `InterfaceRequest`
 which it then returns. Equivalent to the sample code just above is the following
 snippet:
 
-```
+```cpp
   mojo::InterfacePtr<frob::Frobinator> frobinator;
   mojo::InterfaceRequest<frob::Frobinator> frobinator_request =
       mojo::GetProxy(&frobinator);
 ```
 
 #### `mojo::Binding<T>`
 
 Defined in `/third_party/mojo/src/mojo/public/cpp/bindings/binding.h`.
 
 Binds one end of a message pipe to an implementation of service `T`. A message
 sent from the other end of the pipe will be read and, if successfully decoded as
 a `T` message, will invoke the corresponding call on the bound `T`
 implementation. A `Binding<T>` must be constructed over an instance of `T`
 (which itself usually owns said `Binding` object), and its bound pipe is usually
 taken from a passed `InterfaceRequest<T>`.
 
 A common usage pattern looks something like this:
 
-```
+```cpp
 #include "components/frob/public/interfaces/frobinator.mojom.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/binding.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h"
 
 class FrobinatorImpl : public frob::Frobinator {
  public:
   FrobinatorImpl(mojo::InterfaceRequest<frob::Frobinator> request)
       : binding_(this, request.Pass()) {}
   ~FrobinatorImpl() override {}
 
  private:
   // frob::Frobinator:
   void Frobinate() override { /* ... */ }
 
   mojo::Binding<frob::Frobinator> binding_;
 };
 ```
 
 And then we could write some code to test this:
 
-```
+```cpp
 // Fun fact: The bindings generator emits a type alias like this for every
 // interface type. frob::FrobinatorPtr is an InterfacePtr<frob::Frobinator>.
 frob::FrobinatorPtr frobinator;
 scoped_ptr<FrobinatorImpl> impl(
     new FrobinatorImpl(mojo::GetProxy(&frobinator)));
 frobinator->Frobinate();
 ```
 
 This will _eventually_ call `FrobinatorImpl::Frobinate()`. "Eventually," because
 the sequence of events when `frobinator->Frobinate()` is called is roughly as
@@ skipping 146 matching lines @@
 foreseeable future we'll likely be treating `//components` as a sort of
 top-level home for new Mojo apps in the Chromium tree. Any component application
 you build should probably go there. Let's create some basic files to kick things
 off. You may want to start a new local Git branch to isolate any changes you
 make while working through this.
 
 First create a new `//components/hello` directory. Inside this directory we're
 going to add the following files:
 
 **components/hello/main.cc**
-```
+
+```cpp
 #include "base/logging.h"
 #include "third_party/mojo/src/mojo/public/c/system/main.h"
 
 MojoResult MojoMain(MojoHandle shell_handle) {
   LOG(ERROR) << "Hello, world!";
   return MOJO_RESULT_OK;
 };
 ```
 
 **components/hello/BUILD.gn**
+
 ```
 import("//mojo/public/mojo_application.gni")
 
 mojo_native_application("hello") {
   sources = [
     "main.cc",
   ]
   deps = [
     "//base",
     "//mojo/environment:chromium",
@@ skipping 28 matching lines @@
 
 ### Exposing Services
 
 An app that prints `"Hello, world!"` isn't terribly interesting. At a bare
 minimum your app should implement `mojo::ApplicationDelegate` and expose at
 least one service to connecting applications.
 
 Let's update `main.cc` with the following contents:
 
 **components/hello/main.cc**
-```
+
+```cpp
 #include "components/hello/hello_app.h"
 #include "mojo/application/public/cpp/application_runner.h"
 #include "third_party/mojo/src/mojo/public/c/system/main.h"
 
 MojoResult MojoMain(MojoHandle shell_handle) {
   mojo::ApplicationRunner runner(new hello::HelloApp);
   return runner.Run(shell_handle);
 };
 ```
 
 This is a pretty typical looking `MojoMain`. Most of the time this is all you
 want -- a `mojo::ApplicationRunner` constructed over a
 `mojo::ApplicationDelegate` instance, `Run()` with the pipe handle received from
 the shell. We'll add some new files to the app as well:
 
 **components/hello/public/interfaces/greeter.mojom**
+
 ```
 module hello;
 interface Greeter {
   Greet(string name) => (string greeting);
 };
 ```
 
 Note the new arrow syntax on the `Greet` method. This indicates that the caller
 expects a response from the service.
 
 **components/hello/public/interfaces/BUILD.gn**
+
 ```
 import("//third_party/mojo/src/mojo/public/tools/bindings/mojom.gni")
 
 mojom("interfaces") {
   sources = [
     "greeter.mojom",
   ]
 }
 ```
 
 **components/hello/hello_app.h**
-```
+
+```cpp
 #ifndef COMPONENTS_HELLO_HELLO_APP_H_
 #define COMPONENTS_HELLO_HELLO_APP_H_
 
 #include "base/macros.h"
 #include "components/hello/public/interfaces/greeter.mojom.h"
 #include "mojo/application/public/cpp/application_delegate.h"
 #include "mojo/application/public/cpp/interface_factory.h"
 
 namespace hello {
 
@@ skipping 15 matching lines @@
   DISALLOW_COPY_AND_ASSIGN(HelloApp);
 };
 
 }  // namespace hello
 
 #endif  // COMPONENTS_HELLO_HELLO_APP_H_
 ```
 
 
 **components/hello/hello_app.cc**
-```
+
+```cpp
 #include "base/macros.h"
 #include "components/hello/hello_app.h"
 #include "mojo/application/public/cpp/application_connection.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/strong_binding.h"
 
 namespace hello {
 
 namespace {
 
@@ skipping 36 matching lines @@
   new GreeterImpl(request.Pass());
 }
 
 }  // namespace hello
 ```
 
 And finally we need to update our app's `BUILD.gn` to add some new sources and
 dependencies:
 
 **components/hello/BUILD.gn**
+
 ```
 import("//mojo/public/mojo_application.gni")
 
 source_set("lib") {
   sources = [
     "hello_app.cc",
     "hello_app.h",
   ]
   deps = [
     "//base",
@@ skipping 28 matching lines @@
 test!
 
 ### App Tests
 
 App tests run inside a test application, giving test code access to a shell
 which can connect to one or more applications-under-test.
 
 First let's introduce some test code:
 
 **components/hello/hello_apptest.cc**
-```
+
+```cpp
 #include "base/bind.h"
 #include "base/callback.h"
 #include "base/logging.h"
 #include "base/macros.h"
 #include "base/run_loop.h"
 #include "components/hello/public/interfaces/greeter.mojom.h"
 #include "mojo/application/public/cpp/application_impl.h"
 #include "mojo/application/public/cpp/application_test_base.h"
 
 namespace hello {
@@ skipping 95 matching lines @@
 
 This is exploited by the definition of
 `mojo::ApplicationConnection::ConnectToService<T>`, which uses `T::Name_` as the
 name of the service to connect to. The type `T` in this context is inferred from
 the `InterfacePtr<T>*` argument. You can inspect the definition of
 `ConnectToService` in `/mojo/application/public/cpp/application_connection.h`
 for additional clarity.
 
 We could have instead written this code as:
 
-```
+```cpp
 mojo::URLRequestPtr app_url = mojo::URLRequest::New();
 app_url->url = "mojo::hello";
 
 mojo::ServiceProviderPtr services;
 application_impl()->shell()->ConnectToApplication(
     app_url.Pass(), mojo::GetProxy(&services),
     // We pass a null provider since we aren't exposing any of our own
     // services to the target app.
     mojo::ServiceProviderPtr());
 
@@ skipping 34 matching lines @@
 Applications can be set up to run within the browser process via
 `ContentBrowserClient::RegisterInProcessMojoApplications`. This method populates
 a mapping from URL to `base::Callback<scoped_ptr<mojo::ApplicationDelegate>()>`
 (_i.e._, a factory function which creates a new `mojo::ApplicationDelegate`
 instance), so registering a new app means adding an entry to this map.
 
 Let's modify `ChromeContentBrowserClient::RegisterInProcessMojoApplications`
 (in `//chrome/browser/chrome_content_browser_client.cc`) by adding the following
 code:
 
-    apps->insert(std::make_pair(GURL("mojo:hello"),
-                                base::Bind(&HelloApp::CreateApp)));
+```cpp
+apps->insert(std::make_pair(GURL("mojo:hello"),
+                            base::Bind(&HelloApp::CreateApp)));
+```
 
 you'll also want to add the following convenience method to your `HelloApp`
 definition in `//components/hello/hello_app.h`:
 
-    static scoped_ptr<mojo::ApplicationDelegate> HelloApp::CreateApp() {
-      return scoped_ptr<mojo::ApplicationDelegate>(new HelloApp);
-    }
+```cpp
+static scoped_ptr<mojo::ApplicationDelegate> HelloApp::CreateApp() {
+  return scoped_ptr<mojo::ApplicationDelegate>(new HelloApp);
+}
+```
 
 This introduces a dependency from `//chrome/browser` on to
 `//components/hello:lib`, which you can add to the `"browser"` target's deps in
 `//chrome/browser/BUILD.gn`. You'll of course also need to include
 `"components/hello/hello_app.h"` in `chrome_content_browser_client.cc`.
 
 That's it! Now if an app comes to the shell asking to connect to `"mojo:hello"`
 and app is already running, it'll get connected to our `HelloApp` and have
 access to the `Greeter` service. If the app wasn't already running, it will
 first be launched on a new thread.
 
 ### Connecting From the Browser
 
 We've already seen how apps can connect to each other using their own private
 shell proxy, but the vast majority of Chromium code doesn't yet belong to a Mojo
 application. So how do we use an app's services from arbitrary browser code? We
 use `content::MojoAppConnection`, like this:
 
-```
+```cpp
 #include "base/bind.h"
 #include "base/logging.h"
 #include "components/hello/public/interfaces/greeter.mojom.h"
 #include "content/public/browser/mojo_app_connection.h"
 
 void LogGreeting(const mojo::String& greeting) {
   LOG(INFO) << greeting;
 }
 
 void GreetTheWorld() {
@@ skipping 47 matching lines @@
 run out-of-process and unsandboxed (which you **probably do not**), you can
 register its URL via
 `ContentBrowserClient::RegisterUnsandboxedOutOfProcessMojoApplications`.
 
 ## Connecting From `RenderFrame`
 
 We can also connect to Mojo apps from a `RenderFrame`. This is made possible by
 `RenderFrame`'s `GetServiceRegistry()` interface. The `ServiceRegistry` can be
 used to acquire a shell proxy and in turn connect to an app like so:
 
-```
+```cpp
 void GreetWorld(content::RenderFrame* frame) {
   mojo::ShellPtr shell;
   frame->GetServiceRegistry()->ConnectToRemoteService(
       mojo::GetProxy(&shell));
 
   mojo::URLRequestPtr request = mojo::URLRequest::New();
   request->url = "mojo:hello";
 
   mojo::ServiceProviderPtr hello_services;
   shell->ConnectToApplication(
@@ skipping 20 matching lines @@
 
 This is still a work in progress and might not really take shape until the
 Blink+Chromium merge. In the meantime there are some end-to-end WebUI examples
 in `/content/browser/webui/web_ui_mojo_browsertest.cc`. In particular,
 `WebUIMojoTest.ConnectToApplication` connects from a WebUI frame to a test app
 running in a new utility process.
 
 ## FAQ
 
 Nothing here yet!