The “content” module is located insrc/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, e.g. extensions/autofill/spelling etc.
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 intosrc/content (content not chrome :) ).
content should only contain code that is required to implement the web platform. Generally, a feature belongs in this category if and only if all of the following are true:
In contrast, many features that are common to modern web browsers do not satisfy these criteria and thus, are not implemented incontent. A non-exhaustive list:
Instead, these features are implemented inchrome, whilecontent only provides generic extension points that allow these features to subscribe to the events they require. Some features will require adding new extension points: for more information, seeHow to Add New Features (without bloating RenderView/RenderViewHost/WebContents).
Finally, there are a number of browser features that require interaction with online services supplied by the vendor, e.g. from the above list, Safe Browsing, Translate, Sync, and Autofill all require various network services to function. Thechrome layer is the natural place to encapsulate that vendor-specific integration behavior. For the rare cases where a web platform feature implemented incontent has a dependency on a network service (e.g. the network location service used by Geolocation),content should provide a way for the embedder to inject an endpoint (e.g.chrome might provide the service URL to use). Thecontent module itself must remain generic, with no hardcoded vendor-specific logic.
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.
TheContent 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 perHow 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 aContentClient 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 iscontent doesn't depend on chrome at all (see the metabug and all bugs it depends on). We now have a basic browser built on top ofcontent (“content_shell”) that renders pages usingcontent 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 forcontent's unit tests incontent_unittests, and integration tests incontent_browsertests.
content is built as a separate dll to speed up the build.
We‘ve created an API aroundcontent, similar to our Blink API. This isolates embedders from content’s inner workings, and makes it clear to people working on content which methods are used by embedders.
Top-levelcontent OWNERS are reviewers who are qualified to review changes across all ofcontent and are responsible for its architecture. In general,content subdirectories will have specific owners who are the experts in reviewing that code, and top-level owners will defer to subdirectory owners as needed. For large architectural changes tocontent, all owners should loop incontent-owners@chromium.org to give others a chance to post suggestions. This applies to changes large enough to warrant a design doc.
To become a content/OWNER, candidates are expected to show substantial contributions tocontent in recent past that demonstrate knowledge of the core architecture and design principles, including both the browser process side and the renderer side. To become a top-level owner, please follow the following process:
Become an owner in a fewcontent subdirectories and establish yourself as an expert reviewer in those areas.
Find 1-2 current top-level owners who can become your “sponsors” for an owner nomination. Work with them to (1) review your technical changes incontent to gain trust in your technical work and (2) shadow-reviewcontent changes that you also review to gain trust in you as a reviewer. Once ready, your sponsors will nominate you for ownership by sending an email to the current top-level owners.
A typical nomination includes:
content, and which concepts they covered.git shortlog -s --author=<username> content/browser.For reference, a top-levelcontent OWNER is expected to be familiar with most (but not necessarily all) of the following core parts ofcontent:
content interacts with compositing and input handling.content/browser andcontent/renderer and/orblink/renderer.ChildProcessSecurityPolicy).WebContentsObserver,ContentBrowserClient, andNavigationThrottle.content embedders beyond //chrome (e.g., Android Webview).Correspondingly, a top-levelcontent OWNER is typically familiar with most of the following corecontent classes:
Render(Frame|FrameProxy|Process|Widget|View)HostRender(Frame|Widget|Thread)WebContents andWebContentsObserverFrameTree andFrameTreeNodeRenderFrameHostManagerNavigationHandle andNavigationRequest, their ownership and lifetimePage vsRenderFrameHost vs blink'sDocument,RenderDocumentHostUserData/NavigationHandleUserData, and associated lifetime issues.SiteInstance andBrowsingInstance,SiteInfoNavigationController,NavigationEntry vsFrameNavigationEntryChildProcessSecurityPolicyBrowserContext,StoragePartitionContentBrowserClient