Fix sample code in Mojo-in-Chromium markdown docs

docs/mojo_in_chromium.md

 # Mojo in Chromium
 
 This document is intended to serve as a Mojo primer for Chromium developers. No
 prior knowledge of Mojo is assumed.
 
 [TOC]
 
 ## Should I Bother Reading This?
 
 If you're planning to build a Chromium feature that needs IPC and you aren't
@@ skipping 106 matching lines @@
 // src/components/frob/frobinator_impl.cc
 
 #include "components/frob/public/interfaces/frobinator.mojom.h"
 #include "mojo/public/cpp/bindings/binding.h"
 #include "mojo/public/cpp/bindings/interface_request.h"
 
 namespace frob {
 
 class FrobinatorImpl : public mojom::Frobinator {
  public:
-  FrobinatorImpl(mojo::InterfaceRequest<mojom::Frobinator> request)
+  FrobinatorImpl(mojom::FrobinatorRequest request)
       : binding_(this, std::move(request)) {}
   ~FrobinatorImpl() override {}
 
   // mojom::Frobinator:
   void Frobinate() override { DLOG(INFO) << "I can't stop frobinating!"; }
 
  private:
   mojo::Binding<mojom::Frobinator> binding_;
 };
 
 }  // namespace frob
 ```
 
 The first thing to note is that `mojo::Binding<T>` *binds* one end of a message
 pipe to an implementation of a service. This means it watches that end of the
 pipe for incoming messages; it knows how to decode messages for interface `T`,
 and it dispatches them to methods on the bound `T` implementation.
 
-`mojo::InterfaceRequest<T>` is essentially semantic sugar for a strongly-typed
-message pipe endpoint. A common way to create new message pipes is via the
-`GetProxy` call defined in `interface_request.h`:
+`mojom::FrobinatorRequest` is a generated type alias for
+`mojo::InterfaceRequest<mojom::Frobinator>` and is essentially semantic sugar
+for a strongly-typed message pipe endpoint. A common way to create new message
+pipes is via the `GetProxy` call defined in `interface_request.h`:
 
 ```
 mojom::FrobinatorPtr proxy;
-mojo::InterfaceRequest<mojom::Frobinator> request = mojo::GetProxy(&proxy);
+mojom::FrobinatorRequest request = mojo::GetProxy(&proxy);
 ```
 
 This creates a new message pipe with one end owned by `proxy` and the other end
 owned by `request`. It has the nice property of attaching common type
 information to each end of the pipe.
 
 Note that `InterfaceRequest<T>` doesn't actually **do** anything. It just scopes
 a pipe endpoint and associates it with an interface type at compile time. As
 such, other typed service binding primitives such as `mojo::Binding<T>` take
 these objects as input when they need an endpoint to bind to.
@@ skipping 95 matching lines @@
 takes a pipe endpoint and does something with it. It's expected that you'll
 either bind it to a service implementation of some kind or you will close it, effectively rejecting the connection request.
 
 We can build a simple browser-side `FrobinatorImpl` service that has access to a
 `BrowserContext` for any frame which connects to it:
 
 ```
 #include "base/macros.h"
 #include "components/frob/public/interfaces/frobinator.mojom.h"
 #include "content/public/browser/browser_context.h"
-#inlcude "mojo/public/cpp/system/interface_request.h"
-#inlcude "mojo/public/cpp/system/message_pipe.h"
-#inlcude "mojo/public/cpp/system/strong_binding.h"
+#include "mojo/public/cpp/system/interface_request.h"
+#include "mojo/public/cpp/system/strong_binding.h"
 
 namespace frob {
 
 class FrobinatorImpl : public mojom::Frobinator {
  public:
   FrobinatorImpl(content::BrowserContext* context,
-                 mojo::InterfaceRequest<mojom::Frobinator> request)
+                 mojom::FrobinatorRequest request)
       : context_(context), binding_(this, std::move(request)) {}
   ~FrobinatorImpl() override {}
 
   // A factory function to use in conjunction with ServiceRegistry.
   static void Create(content::BrowserContext* context,
-                     mojo::InterfaceRequest<mojom::Frobinator> request) {
+                     mojom::FrobinatorRequest request) {
     // See comment below for why this doesn't leak.
-    new FrobinatorImpl(context,
-                       mojo::MakeRequest<mojom::Frobinator>(std::move(pipe)));
+    new FrobinatorImpl(context, std::move(request));
   }
 
  private:
   // mojom::Frobinator:
   void Frobinate() override { /* ... */ }
 
   content::BrowserContext* context_;
 
   // A StrongBinding is just like a Binding, except that it takes ownership of
   // its bound implementation and deletes itself (and the impl) if and when the
@@ skipping 37 matching lines @@
 
 This is a work in progress. TL;DR: We'll also soon begin using Mojo services
 from Blink so that the platform layer can consume browser services
 directly via Mojo. The long-term goal there is to eliminate `content/renderer`.
 
 ## Questions, Discussion, etc.
 
 A good place to find highly concentrated doses of people who know and care
 about Mojo in Chromium would be the [chromium-mojo](https://goo.gl/A4ebWB)
 mailing list[.](https://goo.gl/L70ihQ)