This document is an overview of extensions concepts, terms, and architecture. The target audience is engineers working on extension support code in the browser, not extension authors. See also the public extensions documentation.
- Manifest: a JSON file stored inside the extension bundle which describes the extension, the capabilities it needs, and many other things about it. The manifest file format doc gives a user-facing overview.
- Action: an action is one of the ways an extension can expose functionality to a user. There are three types: page actions, browser actions, and regular actions. Actions add buttons to the toolbar or to the extension menu.
- Permission: the ability of an extension to access a specific API. Most things extensions can do are controlled by permissions. See permissions for more details.
- Extension renderer: because extensions are logically their own web environments, each extension may have a renderer process that hosts its content. These renderers are annotated in the task manager as “Extension: Name”.
- Component extension: an extension that is part of the browser. Component extensions are not user-visible, generally can't be configured or disabled, and may have special permissions. A component extension is so named because it is logically a component of the browser that happens to be an extension.
An instance of class Extension represents a single installed extension. Instances of this class are mostly immutable, and are often passed around as
An instance of this class represents the manifest of an Extension. An Extension has (and owns) exactly one Manifest. The Manifest contains the parsed JSON data from an extension's manifest.json.
An instance of this class manages much of the state needed to manipulate and use extensions. It controls many subsidiary services and controllers. It also contains an extensions::ExtensionService, which is a mostly-historical grab bag that is still used for many operations.
TODO(ellyjones): Move this to a separate manifest.md doc?
These two cooperating classes allow for manifest parsing to be modular. An instance of ManifestHandler receives the manifest and parses data out of it as desired, attaching data to the Extension in question via
extensions::Extension::SetManifestData. If you were adding a new field to the manifest, you would:
- Create a new ManifestData subclass to store whatever you need to store per-Extension
- Create a new ManifestHandler subclass to parse an Extension's manifest
- Register the class from (2) in
- Grab the ManifestData out of the Extension via
extensions::Extension::GetManifestData as needed. Conventionally, one adds a static method to the ManifestData subclass from (1) to retrieve it from an Extension.
TODO(ellyjones): How does extension sync work?
Extension Process Model
TODO(ellyjones): Write some words!