Add chrome.searchEnginesPrivate API and Search Settings page.

chrome/common/extensions/api/_permission_features.json

Index: chrome/common/extensions/api/_permission_features.json
diff --git a/chrome/common/extensions/api/_permission_features.json b/chrome/common/extensions/api/_permission_features.json
index de15be244324bdc14c4839043c6798deeb81f2d4..5f32b7d08a31a1fb5bf529bb05280a24f2e2c919 100644
--- a/chrome/common/extensions/api/_permission_features.json
+++ b/chrome/common/extensions/api/_permission_features.json
@@ -869,6 +869,12 @@
     "extension_types": ["platform_app"],
     "location": "component"
   },
+  "searchEnginesPrivate": {
+    "channel": "trunk",
+    "extension_types": ["extension", "platform_app"],
+    "platforms": ["chromeos", "mac", "win", "linux"],

[not at google - send to devlin, 2015/04/22 19:32:59]

I see that settingsPrivate did enumerate all of these; but would "all" be
enough?

[Oren Blasberg, 2015/04/22 22:36:11]

I didn't know there was an "all" since there is no "all" in this file anywhere
-- do I need to put "all" explicitly or does omitting the "platforms" altogether
yield that functionality?

[not at google - send to devlin, 2015/04/22 22:43:51]

Oh right, yes, probably omitting it is even better :-)

[Oren Blasberg, 2015/04/22 22:59:18]

Removed altogether.

+    "whitelist": []

[not at google - send to devlin, 2015/04/22 19:32:59]

An empty whitelist is just parsed as no whitelist, i.e. it has no effect and
this means that any extension on trunk is able to call these APIs. It's fine
since it's trunk, but it could be a disaster if that was accidentally changed
(it's also misleading like this).

Is the goal to have the settings app be a component extension? In that case, you
could put "location": "component" here instead, and then add a TODO to whitelist
the specific ID rather than all component extensions, potentially.

Same for settingsPrivate.

[Oren Blasberg, 2015/04/22 22:36:10]

Oh wow, didn't realize that! Thanks. 

Our original plan was for the new Settings to be a Chrome app that's bundled
with the browser. Is that what you meant by "component extension"? 

However, we've decided to defer that approach due to some technical issues we
ran into. Instead we are implementing it using just a WebUI that's hosted at
chrome://md-settings (for now, and later at chrome://settings when it's done).
Hence the "matches" section in _api_features.json.

Given that that's the case, how do we achieve having the API only working from
those whitelisted URLs and nowhere else?

[not at google - send to devlin, 2015/04/22 22:43:51]

Ah right. In that case you don't even need a permission at all - just have the
entry in _api_features.json contain that single rule, exposing it to WebUI. Same
for settingsPrivate.

[Oren Blasberg, 2015/04/22 22:59:19]

Cool, thanks. Removed from here, and will remove for settingsPrivate in a
separate CL as well.

BTW, how does removing this impact the JS side of our browser test? Is there a
way to simulate being on the whitelisted host like chrome://settings from the
test.js so that it has access to the chrome.settingsPrivate API?

[not at google - send to devlin, 2015/04/22 23:01:26]

If your browser test is implemented as an extension... then yeah, you'll have a
problem, and you'll need to add back rules.

Of course, it's fairly easy to implement tests based in WebUI, you'll just get a
different test framework. I don't know anything about WebUI's.

[Oren Blasberg, 2015/04/22 23:39:57]

OK. In order to be a bit more future proof I'm going to do the location:
component approach with the TODO for now. Thanks for the tip.

+  },
   "screensaver": {
     "channel": "stable",
     "extension_types": ["legacy_packaged_app", "hosted_app", "platform_app"]