Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(1288)

Side by Side Diff: chrome/common/extensions/api/_features.md

Issue 2257933003: [Extensions] Add starter documentation for extension features (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Created 4 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(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.
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698