From ee1afd173321a2172ae14db92a800db7347e491c Mon Sep 17 00:00:00 2001 From: Oksana Zhuravlova Date: Sat, 15 Feb 2020 00:47:27 +0000 Subject: [PATCH] [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 Reviewed-by: Dale Curtis Commit-Queue: Oksana Zhuravlova Cr-Commit-Position: refs/heads/master@{#741675} --- docs/mojo_and_services.md | 45 ++++++--------------------------------- docs/security/mojo.md | 2 +- media/mojo/README.md | 2 +- 3 files changed, 8 insertions(+), 41 deletions(-) diff --git a/docs/mojo_and_services.md b/docs/mojo_and_services.md index 52a59570fd9c99..8ffd2f3dd52542 100644 --- a/docs/mojo_and_services.md +++ b/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 diff --git a/docs/security/mojo.md b/docs/security/mojo.md index 5c51e8b9b28c6a..b9479610a69547 100644 --- a/docs/security/mojo.md +++ b/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 and > ). diff --git a/media/mojo/README.md b/media/mojo/README.md index be743355540dad..8ed718d7198e72 100644 --- a/media/mojo/README.md +++ b/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: