See an older diagram at: https://www.chromium.org/developers/content-module.
The diagram illustrates the layering of the different modules. A module can include code directly from lower modules. However, a module can not include code from a module that is higher than it. This is enforced through DEPS rules. Modules can implement embedder APIs so that modules lower than them can call them. Examples of these APIs are the WebKit API and the Content API.
The Content API is how code in content can indirectly call Chrome. Where possible, Chrome features try to hook in by filtering IPCs and listening to events per How to Add New Features (without bloating RenderView/RenderViewHost/WebContents). When there isn't enough context (i.e. callback from WebKit) or when the callback is a one-off, we have a
ContentClient interface that the embedder (Chrome) implements.
ContentClient is available in all processes. Some processes also have their own callback API as well, i.e.
The current status is
content doesn't depend on chrome at all (see the meta bug and all bugs it depends on). We now have a basic browser built on top of
content_shell”) that renders pages using
content on all platforms. This allow developers working on the web platform and core code to only have to build/test content, instead of all of chrome.
We have a separate target for
content's unit tests in
content_unittests, and integration tests in
content is build at a separate dll to speed up the build.
We‘ve created an API around
content, similar to our WebKit API. This isolates embedders from content’s inner workings, and makes it clear to people working on content which methods are used by embedders.