[mojo][doc] Remove InterfaceProvider references

This change replaces InterfaceProvider references with
BrowserInterfaceBroker in the context of interfaces
exposed by the browser.

Change-Id: I6ee3e4b97cfd84a4c0fdc9fd968ea9184b15a306
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2057943
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Oksana Zhuravlova <oksamyt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#741675}

docs/mojo_and_services.md

@@ -729,45 +729,11 @@ renderered content, installed extensions in the renderer, *etc.* For this
 reason, interface brokering decisions are increasingly being made by the
 browser.
 
-There are two ways this is done: the Deprecated way and the New way.
-
-#### The Deprecated Way: InterfaceProvider
-
-This is built on the concept of **interface filters** and the
-**`InterfaceProvider`** interface. It is **deprecated** and new features should
-use [The New Way](#The-New-Way_Interface-Brokers) instead. This section only
-briefly covers practical usage in Chromium.
-
-The `content_browser` manifest exposes capabilities on a few named interface
-filters, the main one being `"navigation:frame"`. There are others scoped to
-different worker contexts, *e.g.* `"navigation:service_worker"`.
-`RenderProcessHostImpl` or `RenderFrameHostImpl` sets up an `InterfaceProvider`
-for each known execution context in the corresponding renderer, filtered through
-the Service Manager according to one of the named filters.
-
-The practical result of all this means the interface must be listed in the
-`content_browser` manifest under the
-`ExposeInterfaceFilterCapability_Deprecated("navigation:frame", "renderer", ...)`
-entry, and a corresponding interface request handler must be registered with the
-host's `registry_` in
-[`RenderFrameHostImpl::RegisterMojoInterfaces`](https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.cc?rcl=0a23c78c57ecb2405837155aa0a0def7b5ba9c22&l=3971)
-
-Similarly for worker contexts, an interface must be exposed by the `"renderer"`
-capability on the corresponding interface filter
-(*e.g.*, `"navigation:shared_worker"`) and a request handler must be registered
-within
-[`RendererInterfaceBinders::InitializeParameterizedBinderRegistry`](https://cs.chromium.org/chromium/src/content/browser/renderer_interface_binders.cc?rcl=0a23c78c57ecb2405837155aa0a0def7b5ba9c22&l=116).
-
-The best way to understand all of this after reading this section is to look at
-the linked code above and examine a few examples. They are fairly repetitive.
-For additional convenience, here is also a link to the `content_browser`
-[manifest](https://cs.chromium.org/chromium/src/content/public/app/content_browser_manifest.cc).
-
-#### The New Way: Interface Brokers
-
-Rather than the confusing spaghetti of interface filter logic, we now define an
-explicit mojom interface with a persistent connection between a renderer's
-frame object and the corresponding `RenderFrameHostImpl` in the browser process.
+#### Interface Brokers
+
+We define an explicit mojom interface with a persistent connection
+between a renderer's frame object and the corresponding
+`RenderFrameHostImpl` in the browser process.
 This interface is called
 [`BrowserInterfaceBroker`](https://cs.chromium.org/chromium/src/third_party/blink/public/mojom/browser_interface_broker.mojom?rcl=09aa5ae71649974cae8ad4f889d7cd093637ccdb&l=11)
 and is fairly easy to work with: you add a new method on `RenderFrameHostImpl`:
@@ -792,6 +758,7 @@ void PopulateFrameBinders(RenderFrameHostImpl* host,
 }
 ```
 
+TODO: add information about workers and embedders.
 
 ### Exposing Browser Interfaces to Render Processes
 

docs/security/mojo.md

@@ -164,7 +164,7 @@ callee to trust the caller.
 
 ### Do not send unnecessary or privilege-presuming data
 
-> Each `InterfaceProvider` for frames and workers is strongly associated with an
+> Each `BrowserInterfaceBroker` for frames and workers is strongly associated with an
 > origin. Where possible, prefer to use this associated origin rather than
 > sending it over IPC. (See <https://crbug.com/734210> and
 > <https://crbug.com/775792/>).

media/mojo/README.md

@@ -335,7 +335,7 @@ these services (e.g. to handle navigation).
 In `MediaInterfaceProxy`, when we request `media::mojom::InterfaceFactory` in
 the `MediaService` or `CdmService`, we call `GetFrameServices()` to configure
 which secure auxiliary services are exposed to the remote components over the
-separate `service_manager::mojom::InterfaceProvider`.
+separate `blink::mojom::BrowserInterfaceBroker`.
 
 Currently only the remote CDM needs secure auxiliary services. This is a list of
 currently supported services: