Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 # Extension Features Files | |
| 2 | |
| 3 [TOC] | |
| 4 | |
| 5 ## Summary | |
| 6 | |
| 7 The Extension features files specify the different requirements for extension | |
| 8 feature availability. | |
| 9 | |
| 10 An **extension feature** can be any component of extension capabilities. Most | |
| 11 notably, this includes extension APIs, but there are also more structural or | |
| 12 behavioral features, such as web accessible resources or event pages. | |
| 13 | |
| 14 ## Files | |
| 15 | |
| 16 There are four different feature files used: | |
| 17 [\_api\_features](https://chromium.googlesource.com/chromium/src/+/master/chrome /common/extensions/api/_api_features.json): | |
|
lazyboy
2016/08/19 17:58:55
Precede each files with "* " for bullets?
Devlin
2016/08/19 18:58:15
Done.
| |
| 18 Specifies the requirements for API availability. If an extension doesn't satisfy | |
| 19 the requirements, the API will not be accessible in the extension's code. | |
| 20 [\_permission\_features](https://chromium.googlesource.com/chromium/src/+/master /chrome/common/extensions/api/_permission_features.json): | |
| 21 Specifies the requirements for permission availability. If an extension doesn't | |
| 22 satisfy the requirements, the permission will not be granted and the extension | |
| 23 will have an install warning. | |
| 24 [\_manifest\_features](https://chromium.googlesource.com/chromium/src/+/master/c hrome/common/extensions/api/_manifest_features.json): | |
| 25 Specifies the requirements for manifest entry availability. If an extension | |
| 26 doesn't satisfy the requirements, the extension will fail to load with an error. | |
| 27 [\_behavior\_features](https://chromium.googlesource.com/chromium/src/+/master/c hrome/common/extensions/api/_behavior_features.json): | |
| 28 Specifies the requirements for miscellaneous extension behaviors. This should | |
| 29 typically not be used. | |
| 30 | |
| 31 Note that these files may be present under chrome/common/extensions/api, as well | |
| 32 as under extensions/common/api and extensions/shell/common/api. | |
| 33 | |
| 34 ## Grammar | |
| 35 | |
| 36 The feature files are written in JSON. Each file contains a single JSON object | |
| 37 with properties for each feature. | |
| 38 | |
| 39 ``` | |
| 40 { | |
| 41 "feature1": <definition>, | |
| 42 "feature2": <definition>, | |
| 43 ... | |
| 44 } | |
| 45 ``` | |
| 46 | |
| 47 ### Simple and Complex Features | |
| 48 | |
| 49 Most features are known as "simple" features. These are features whose | |
| 50 definition is a single object that contains the properties describing the | |
| 51 criteria for availability. A simple feature might look like this: | |
| 52 ``` | |
| 53 "feature1": { | |
| 54 "dependencies": ["permission:feature1"], | |
| 55 "contexts": ["blessed_extension"] | |
| 56 } | |
| 57 ``` | |
| 58 `feature1` has a single definition, which says for it to be available, a | |
| 59 permission must be present and it must be executed from a blessed context. | |
| 60 (These concepts are covered more later.) | |
|
asargent_no_longer_on_chrome
2016/08/19 19:33:16
suggestion: "...are covered more later in this doc
Devlin
2016/08/19 21:00:57
Done.
| |
| 61 | |
| 62 Features can also be "complex". A complex feature has a list of objects to | |
| 63 specify multiple groups of possible properties. A complex feature could look | |
| 64 like this: | |
| 65 ``` | |
| 66 "feature1": [{ | |
| 67 "dependencies": ["permission:feature1"], | |
| 68 "contexts": ["blessed_extension"] | |
| 69 }, { | |
| 70 "dependencies": ["permission:otherPermission"], | |
| 71 "contexts": ["blessed_extension", "unblessed_extension"] | |
| 72 }] | |
| 73 ``` | |
| 74 | |
| 75 With complex features, if either of the definitions are matched, the feature | |
|
asargent_no_longer_on_chrome
2016/08/19 19:33:16
suggestion: you might also say something like "the
Devlin
2016/08/19 21:00:57
I like it, done.
| |
| 76 is available. Complex features should frequently be avoided, as it makes the | |
| 77 logic more involved and slower. | |
| 78 | |
| 79 ### Inheritance | |
| 80 | |
| 81 By default, features inherit from parents. A feature's ancestry is specified by | |
| 82 it's name, where a child feature is the parent's name followed by a '.' and the | |
|
asargent_no_longer_on_chrome
2016/08/19 19:33:16
grammar nazi sez: "it's" -> "its"
Devlin
2016/08/19 21:00:57
d'oh! I catch this in reading, but never writing.
| |
| 83 child's name. That is, `feature1.child` is the child of `feature1`. Inheritance | |
| 84 can carry for multiple levels (e.g. `feature1.child.child`), but this is rarely | |
| 85 (if ever) useful. | |
| 86 | |
| 87 A child feature inherits all the properties of its parent, but can choose to | |
| 88 override them or add additional properties. Take the example: | |
| 89 ``` | |
| 90 "feature1": { | |
| 91 "dependencies": ["permission:feature1"], | |
| 92 "contexts": ["blessed_extension"] | |
| 93 }, | |
| 94 "feature1.child": { | |
| 95 "contexts": ["unblessed_extension"], | |
| 96 "extension_types": ["extension"] | |
| 97 } | |
| 98 ``` | |
| 99 | |
| 100 In this case, `feature1.child` will effective have the properties | |
|
lazyboy
2016/08/19 17:58:55
"will effectively have the properties:"
Devlin
2016/08/19 18:58:15
Done.
| |
| 101 ``` | |
| 102 "dependencies": ["permission:feature1"], # inherited from feature1 | |
| 103 "contexts": ["unblessed_extension"], # inherited value overridden by child | |
| 104 "extension_types": ["extension] # specified by child | |
| 105 ``` | |
| 106 | |
| 107 If you don't want a child to inherit any features from the parent, add the | |
| 108 property `"noparent": true`. | |
|
asargent_no_longer_on_chrome
2016/08/19 19:33:16
It would be nice to add a sentence here with an ex
Devlin
2016/08/19 21:00:57
Done.
| |
| 109 | |
| 110 If the parent of a feature is a complex feature, the feature system needs to | |
| 111 know which parent to inherit from. To do this, add the property | |
| 112 `"default_parent": true` to one of the feature definitions in the parent | |
| 113 feature. | |
| 114 | |
| 115 ## Properties | |
| 116 | |
| 117 The following properties are supported in the feature system. | |
| 118 | |
| 119 ### blacklist | |
| 120 | |
| 121 The `blacklist` property specifies a list of ID hashes for extensions that | |
|
lazyboy
2016/08/19 17:58:55
Add a todo to describe about how these hashes can
Devlin
2016/08/19 18:58:15
Added a note to see _api_features.json, since ther
| |
| 122 cannot access a feature. | |
| 123 | |
| 124 Accepted values are lists of id hashes. | |
| 125 | |
| 126 ### channel | |
| 127 | |
| 128 The `channel` property specifies a maximum channel for the feature availability. | |
| 129 That is, specifying `dev` means that the feature is available on `dev`, | |
| 130 `canary`, and `trunk`. | |
| 131 | |
| 132 Accepted values are a single string from `trunk`, `canary`, `dev`, `beta`, and | |
| 133 `stable`. | |
| 134 | |
| 135 ### command\_line\_switch | |
| 136 | |
| 137 The `command_line_switch` property specifies a command line switch that must be | |
|
lazyboy
2016/08/19 17:58:55
s/command line switch/command line switch (without
Devlin
2016/08/19 18:58:16
Done, but put in the "accepted values" sentence.
| |
| 138 present for the feature to be available. | |
| 139 | |
| 140 Accepted values are a single string for the command line switch. | |
| 141 | |
| 142 ### component\_extensions\_auto\_granted | |
| 143 | |
| 144 The `component_extensions_auto_granted` specifies whether or not component | |
| 145 extensions should be automatically granted access to the feature. By default, | |
| 146 this is `true`. | |
| 147 | |
| 148 The only accepted value is `false` (since true is the default). | |
|
lazyboy
2016/08/19 17:58:55
not sure: The only accepted boolean value is..
to
Devlin
2016/08/19 18:58:15
sgtm. Clarity never hurts. (Though it would just
| |
| 149 | |
| 150 ### contexts | |
| 151 | |
| 152 The `contexts` property specifies which JavaScript contexts can access the | |
| 153 feature. All API features must specify at least one context, and only API | |
| 154 features can specify contexts. | |
| 155 | |
| 156 Accepted values are a list of strings from `blessed_extension`, | |
|
lazyboy
2016/08/19 17:58:55
Contexts are fun stuff and also source of confusio
Devlin
2016/08/19 18:58:15
Already done at the bottom. :)
| |
| 157 `blessed_web_page`, `content_script`, `extension_service_worker`, | |
| 158 `web_page`, `webui`, and `unblessed_extension`. | |
| 159 | |
| 160 ### default\_parent | |
| 161 | |
| 162 The `default_parent` property specifies a feature definition from a complex | |
| 163 feature to be used as the parent for any children. See also Inheritance. | |
| 164 | |
| 165 The only accepted value is `true`. | |
| 166 | |
| 167 ### dependencies | |
| 168 | |
| 169 The `dependencies` property specifies which other features must be present in | |
| 170 order to access this feature. This is useful so that you don't have to | |
| 171 re-specify all the same properties on an API feature and a permission feature. | |
| 172 | |
| 173 A common practice is to put as many restrictions as possible in the | |
| 174 permission or manifest feature so that we warn at extension load, and put | |
| 175 relatively limited properties in an API feature with a dependency on the | |
| 176 manifest or permission feature. | |
| 177 | |
| 178 To specify a dependent feature, use the prefix the feature name with the type | |
| 179 of feature it is, followed by a colon. For example, in order to specify a | |
| 180 dependency on a permission feature `foo`, we would add the dependency entry | |
| 181 `permission:foo`. | |
| 182 | |
| 183 Accepted values are lists of strings specifying the dependent features. | |
| 184 | |
| 185 ### extension\_types | |
| 186 | |
| 187 The `extension_types` properties specifies the different classes of extensions | |
| 188 that can use the feature. It is very common for certain features to only be | |
| 189 allowed in certain extension classes, rather than available to all types. | |
| 190 | |
| 191 Accepted values are lists of strings from `extension`, `hosted_app`, | |
| 192 `legacy_packaged_app`, `platform_app`, `shared_module`, and `theme`. | |
|
asargent_no_longer_on_chrome
2016/08/19 19:33:16
Possibly worth mentioning that "platform_app" mean
Devlin
2016/08/19 21:00:57
I've added a TODO for this. I'm still trying to fi
| |
| 193 | |
| 194 ### location | |
| 195 | |
| 196 The `location` property specifies the required install location of the | |
| 197 extension. | |
| 198 | |
| 199 Accepted values are a single string from `component`, `external_component`, and | |
| 200 `policy`. | |
| 201 | |
| 202 ### internal | |
| 203 | |
| 204 The `internal` property specifies whether or not a feature is considered | |
|
lazyboy
2016/08/19 17:58:55
This is not exposed to developers or something tha
Devlin
2016/08/19 18:58:15
Done.
| |
| 205 internal to Chromium. | |
| 206 | |
| 207 The only accepted value is `true`. | |
| 208 | |
| 209 ### matches | |
| 210 | |
| 211 The `matches` property specifies url patterns which should be allowed to access | |
| 212 the feature. Only API features may specify `matches`, and `matches` only make | |
| 213 sense with a context of either `webui` or `web_page`. | |
| 214 | |
| 215 Accepted values are a list of strings specifying the match patterns. | |
| 216 | |
| 217 ### max\_manifest\_version | |
| 218 | |
| 219 The `max_manifest_version` property specifies the maximum manifest version to be | |
| 220 allowed to access a feature. Extensions with a greater manifest version cannot | |
| 221 access the feature. | |
| 222 | |
| 223 The only accepted value is `1`, as currently the highest possible manifest | |
| 224 version is `2`. | |
| 225 | |
| 226 ### min\_manifest\_version | |
| 227 | |
| 228 The `min_manifest_version` property specifies the minimum manifest version to be | |
| 229 allowed to access a feature. Extensions with a lesser manifest version cannot | |
| 230 access the feature. | |
| 231 | |
| 232 The only accepted value is `2`, as this is currently the highest possible | |
| 233 manifest version. | |
| 234 | |
| 235 ### noparent | |
| 236 | |
| 237 The `noparent` property specifies that a feature should not inherit any | |
| 238 properties from a derived parent. See also Inheritance. | |
| 239 | |
| 240 The only accepted value is `true`. | |
| 241 | |
| 242 ### platforms | |
| 243 | |
| 244 The `platforms` property specifies the properties the feature should be | |
| 245 available on. | |
| 246 | |
| 247 The accepted values are lists of strings from `chromeos`, `mac`, `linux`, and | |
| 248 `win`. | |
| 249 | |
| 250 ### whitelist | |
| 251 | |
| 252 The `whitelist` property specifies a list of ID hashes for extensions that | |
| 253 are the only extensions allowed to access a feature. | |
| 254 | |
| 255 Accepted values are lists of id hashes. | |
| 256 | |
| 257 ## Still to come | |
| 258 | |
| 259 TODO(devlin): Move documentation for how to create ID hashes, possibly move | |
|
lazyboy
2016/08/19 17:58:55
Ah, I notice this now, consolidate my comments abo
Devlin
2016/08/19 18:58:16
TODOs for hashes and contexts are already here, so
| |
| 260 documentation for feature contexts, and add documentation for the compilation | |
| 261 process. Probably also more on requirements for individual features. | |
| OLD | NEW |