Allow API functions and events to have entries in _api_features.json

chrome/common/extensions/api/_api_features.json

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 {
   "app": {
     "channel": "stable",
     "extension_types": ["hosted_app", "extension", "packaged_app"],
     "contexts": [
       "blessed_extension", "unblessed_extension", "content_script", "web_page"
@@ skipping 33 matching lines @@
     "contexts": [
       "blessed_extension", "unblessed_extension", "content_script", "web_page"
     ],
     "matches": ["<all_urls>"]
   },
   "fileBrowserHandlerInternal": {
     "internal": true,
     "channel": "stable",
     "contexts": ["blessed_extension", "unblessed_extension", "content_script"]
   },
+  "runtime": {
+    "channel": "stable",
+    "contexts": ["blessed_extension", "unblessed_extension", "content_script"]

[cduvall, 2013/04/26 02:07:21]

Not sure if this is right or not, or if it needs extension_types.

[not at google - send to devlin, 2013/04/27 01:02:43]

It does need extension types, it's odd that this works.

In any case, not *all* of runtime can be accessed from content scripts. Only the
unprivileged ones. This should be just ["blessed_extension"] then for each
unprivileged entry also have the unblessed/content_script case.

[cduvall, 2013/05/01 02:51:47]

I think without extension_types, it defaults to being available in all of them.
Is there somewhere to check which contexts/extension_types each API should be
available to?

[not at google - send to devlin, 2013/05/01 20:47:04]

yeah, so, these runtime APIs shouldn't be available to hosted apps, and I
believe this change will allow it to be? Either I'm wrong about that - or we
don't test it - ugh!

When constructing the features we should ensure that either it has dependencies
or it specifies extension types (transitively eventually something will check
extension types).

And I was wondering this before, but maybe features should have an "inherit"
property which imports the property from another feature. Most of these would be
much simpler then - the runtime feature would specify extension types, then all
of these sub-features would inherit from it then specify a custom context value.

WDYT? Is it worth doing and/or worth doing now or as a follow up?

[cduvall, 2013/05/01 23:47:10]

I think it would definitely be useful for pretty much any sub-feature. I'll do
it as a follow-up though.

+  },
   "webRequestInternal": {
     "internal": true,
     "channel": "stable",
     "contexts": ["blessed_extension", "unblessed_extension", "content_script"]
   },
   "webstore": {
     // Hosted apps can use the webstore API from within a blessed context.
     "channel": "stable",
     "extension_types": ["hosted_app"],
     "contexts": ["blessed_extension", "web_page"],
     // Any webpage can use the webstore API.
     "matches": ["http://*/*", "https://*/*"]
   }
 }