//content/public is the API exposed to embedders of the content module.
In general, we follow the design of the Blink Public API. This makes it easier for people who're already familiar with it, and also keeps things consistent.
//content/publicshould contain only interfaces, enums, structs and (rarely) static functions.
//content/public/test. We allow concrete classes that chrome test classes derive from or use in here.
//content/publicshould be inside implementation directories, e.g.
//content/public, we do allow
.mojomfiles (see discussion). If a mojom is only used inside content, it should be in
//content/common. If it’s an interface that is implemented or called by content's embedder, then it belongs in
//contentshould be in the
RenderViewObserver) this might cover things like automatic registration/unregistration. Normally we would put this small code in headers, but because of the clang checks against putting code in headers, we’re forced to put it in .cc files (we don't want to make a clang exception for the
content/publicdirectory since that would lead to confusion).
//content/publicbut instead some module that's higher level.
constidentifier can be added to simple getter APIs implemented by content. Don‘t add
constto interfaces implemented by the embedder, where we can’t make assumptions about what the embedder needs to implement it.
RenderViewObserver) should only have void methods. This is because otherwise the order that observers are registered would matter, and we don‘t want that. The only exception is
OnMessageReceived(), which is fine since only one observer class handles each particular IPC, so ordering doesn’t make a difference.
Large parts of the Chromium codebase depend on
//content/public. Some notable directories that depend on it are (parts of)
//weblayer. Some directories in
//components also depend on it, while conversely
//content depends on some components.
Directories that do not depend on content include
When adding and reviewing DEPS changes that take a dependency on content, some things to consider are:
//contentitself or other subdirectories.
git gs <directory>inside
//content. There is no complete automated check at this time.
//content. For example, if it just needs
BrowserThread, you could instead inject the main task runner (or they can grab it from the static getter on creation of their object).
//content/public/testif only test code is needed.
//componentssubdirectories can depend on
//content/public, but be careful of circular dependencies because content depends on some components. Full guidelines for components are in the README.
//component/foo/browsercan only use
//content/public/browser. Some modules/components run only in one process and don't have the explicit directory name.