//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.