//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/public
should 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/public
should be inside implementation directories, e.g. //content/browser
, //content/renderer
etc..._messages.h
files in //content/public
, we do allow .mojom
files (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 //content/public/common
.//content
should be in the "content"
namespace.PAGE_TRANSITION_LINK
in the content::PageTransition
enum.//content/renderer
should use RenderViewImpl
instead of content::RenderView
).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/public
directory since that would lead to confusion).ChromeContentBrowserClient
derives from content::ContentBrowserClient
).foo_impl.h
and not foo.h
.//content/public
but instead some module that's higher level.const
identifier can be added to simple getter APIs implemented by content. Don‘t add const
to interfaces implemented by the embedder, where we can’t make assumptions about what the embedder needs to implement it.WebContentsObserver
, RenderFrameObserver
, 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) //extensions
, //chrome
, and //weblayer
. Some directories in //components
also depend on it, while conversely //content
depends on some components.
Directories that do not depend on content include //third_party/blink
and //services
.
When adding and reviewing DEPS changes that take a dependency on content, some things to consider are:
//content/public
and not //content
itself 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/test
if only test code is needed.//components
subdirectories 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/browser
can only use //content/public/browser
. Some modules/components run only in one process and don't have the explicit directory name.content/public/browser/tts_controller.h
in /chrome/browser/DEPS.