Elly Fong-Jones | a1de2314 | 2020-02-05 20:01:22 | [diff] [blame] | 1 | # Extensions Overview |
| 2 | |
| 3 | This document is an overview of extensions concepts, terms, and architecture. |
| 4 | The target audience is engineers working on extension support code in the |
| 5 | browser, *not* extension authors. See also the [public extensions |
| 6 | documentation]. |
| 7 | |
| 8 | ## Glossary |
| 9 | |
| 10 | * **Extension**: a bundle of HTML, CSS, and Javascript that can interact with |
| 11 | web contents and some parts of the browser UI. There are many types of |
| 12 | extensions; see [extension types] for more details. Each extension has an |
| 13 | **id**, which is a unique string identifying that extension. |
| 14 | * **Manifest**: a JSON file stored inside the extension bundle which describes |
| 15 | the extension, the capabilities it needs, and many other things about it. The |
| 16 | [manifest file format] doc gives a user-facing overview. |
| 17 | * **Action**: an action is one of the ways an extension can expose |
| 18 | functionality to a user. There are three types: [page actions], |
| 19 | [browser actions], and regular actions. Actions add buttons to the toolbar or |
| 20 | to the extension menu. |
Elly Fong-Jones | d591a05 | 2020-02-05 20:29:03 | [diff] [blame] | 21 | * **Permission**: the ability of an extension to access a specific API. Most |
| 22 | things extensions can do are controlled by permissions. See [permissions] |
| 23 | for more details. |
Elly Fong-Jones | a1de2314 | 2020-02-05 20:01:22 | [diff] [blame] | 24 | * **Extension renderer**: because extensions are logically their own web |
| 25 | environments, each extension may have a renderer process that hosts its |
| 26 | content. These renderers are annotated in the task manager as |
| 27 | "Extension: Name". |
| 28 | * **Component extension**: an extension that is part of the browser. Component |
| 29 | extensions are not user-visible, generally can't be configured or disabled, |
| 30 | and may have special permissions. A component extension is so named because it |
| 31 | is logically a *component of the browser* that happens to be an extension. |
| 32 | |
| 33 | ## Key Classes |
| 34 | |
| 35 | ### [extensions::Extension] |
| 36 | |
| 37 | An instance of class Extension represents a single installed extension. |
| 38 | Instances of this class are mostly immutable, and are often passed around as |
| 39 | `scoped_refptr<const Extension>`. |
| 40 | |
| 41 | ### [extensions::Manifest] |
| 42 | |
| 43 | An instance of this class represents the manifest of an Extension. An Extension |
| 44 | has (and owns) exactly one Manifest. The Manifest contains the parsed JSON data |
| 45 | from an extension's manifest.json. |
| 46 | |
| 47 | ### [extensions::ExtensionSystem] |
| 48 | |
| 49 | An instance of this class manages much of the state needed to manipulate and use |
| 50 | extensions. It controls many subsidiary services and controllers. It also |
| 51 | contains an [extensions::ExtensionService], which is a mostly-historical grab |
| 52 | bag that is still used for many operations. |
| 53 | |
| 54 | ### [extensions::Extension::ManifestData] and [extensions::ManifestHandler] |
| 55 | |
| 56 | TODO(ellyjones): Move this to a separate manifest.md doc? |
| 57 | |
| 58 | These two cooperating classes allow for manifest parsing to be modular. An |
| 59 | instance of ManifestHandler receives the manifest and parses data out of it as |
| 60 | desired, attaching data to the Extension in question via |
| 61 | `extensions::Extension::SetManifestData`. If you were adding a new field to the |
| 62 | manifest, you would: |
| 63 | |
| 64 | 1. Create a new ManifestData subclass to store whatever you need to store |
| 65 | per-Extension |
| 66 | 2. Create a new ManifestHandler subclass to parse an Extension's manifest |
| 67 | 3. Register the class from (2) in `extensions::RegisterChromeManifestHandlers` |
| 68 | 4. Grab the ManifestData out of the Extension via |
| 69 | `extensions::Extension::GetManifestData` as needed. Conventionally, one adds |
| 70 | a static method to the ManifestData subclass from (1) to retrieve it from an |
| 71 | Extension. |
| 72 | |
| 73 | ## Sync |
| 74 | |
| 75 | TODO(ellyjones): How does extension sync work? |
| 76 | |
| 77 | ## Extension Process Model |
| 78 | |
| 79 | TODO(ellyjones): Write some words! |
| 80 | |
Elly Fong-Jones | a1de2314 | 2020-02-05 20:01:22 | [diff] [blame] | 81 | [browser actions]: https://developer.chrome.com/extensions/browserAction |
Elly Fong-Jones | a1de2314 | 2020-02-05 20:01:22 | [diff] [blame] | 82 | [extension types]: extension_and_app_types.md |
| 83 | [manifest file format]: https://developer.chrome.com/extensions/manifest |
| 84 | [page actions]: https://developer.chrome.com/extensions/pageAction |
| 85 | [permissions]: permissions.md |
| 86 | [public extensions documentation]: https://developer.chrome.com/extensions |
| 87 | |
| 88 | [extensions::Extension::ManifestData]: https://cs.chromium.org/chromium/src/extensions/common/extension.h |
| 89 | [extensions::ExtensionService]: https://cs.chromium.org/chromium/src/chrome/browser/extensions/extension_service.h |
| 90 | [extensions::ExtensionSystem]: https://cs.chromium.org/chromium/src/extensions/browser/extension_system.h |
| 91 | [extensions::Extension]: https://cs.chromium.org/chromium/src/extensions/common/extension.h |
| 92 | [extensions::ManifestHandler]: https://cs.chromium.org/chromium/src/extensions/common/manifest_handler.h |
| 93 | [extensions::Manifest]: https://cs.chromium.org/chromium/src/extensions/common/manifest.h |