High-level overviewThe "content" module is located in src\content, and is the core code needed to render a page using a multi-process sandboxed browser. It includes all the web platform features (i.e. HTML5) and GPU acceleration. It does not include Chrome features, i.e. extensions/autofill/spelling etc. The goal is that any embedder should be able to build a browser by starting with content, and then pick and choose Chrome features. As the Chromium code has grown, features inevitably hooked into the wrong places, causing layering violations and dependencies that shouldn't exist. It's been hard for developers to figure out what the "best" way is because the APIs (when they existed) and features were together in the same directory. To avoid this happening, and to add a clear separation between the core pieces of the code that render a page using a multi-process browser, consensus was reached to move the core Chrome code into src\content (content not chrome :) ). As discussed above, content should only have the core code needed to render a page. Chrome features use APIs that are provided by content to filter IPCs and get notified of events that they require. How to Add New Features (without bloating RenderView/RenderViewHost/TabContents) describes how to do this. As an example, here's a (non-exhaustive) list of features that are Chrome only, and so are not in content. This means that content code shouldn't have to know anything about them, only providing generic APIs that they can be built upon.
 The diagram above 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/TabContents). 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. ContentBrowserClient/ContentRendererClient/ContentPluginClient. The current status (as of 9/19/2011) is content doesn't depend on chrome at all. We now have a basic content_shell that renders pages using content on Windows, and are working on moving TabContentsViewMac/TabContentsViewGtk to content so that it can work on these platforms as well. We now have content_unittests, and are starting on content_browsertests. content.dll will be ready this week. Once content doesn't depend on chrome, then the next work items are:
In parallel, or once this is done, it would also be useful to separate the dependencies of chrome features. As an example, if someone wants to start with content and add spellcheck+translate, they should be able to build without extensions. We need well-defined APIs between features in order to make this possible. |
|
For Developers >
Content module
Subpages (1):
Content API
|