Add browserAction.enable/disable as alias for pageAction.show/hide.

chrome/common/extensions/api/browser_action.json

Index: chrome/common/extensions/api/browser_action.json
diff --git a/chrome/common/extensions/api/browser_action.json b/chrome/common/extensions/api/browser_action.json
index 68ae6377c8807191f8ed1d89cc0a04d0db5e65d8..379bacb15f80e750aa7e8baa2b270334151c94cb 100644
--- a/chrome/common/extensions/api/browser_action.json
+++ b/chrome/common/extensions/api/browser_action.json
@@ -259,6 +259,34 @@
             ]
           }
         ]
+      },
+      {
+        "name": "enable",
+        "type": "function",
+        "description": "Enables the browser action for a tab. By default, browser actions are enabled.",
+        "parameters": [
+          {
+            "type": "integer",
+            "optional": true,
+            "name": "tabId",

[not at google - send to devlin, 2012/07/23 11:07:48]

Sorry I just noticed this (and I reviewed the change that added it, ah well):
why is scriptBadge.show/hide (and therefore browserAction.enable/disable)
different to all other extension action functions? Those take a "details" object
(often with only a single property "tabId") but this just takes a single integer
for tabId.

For consistency, we might want to change that (and perhaps also consider making
these functions that accept just a single "tabId" property to accept an integer
too, like, using "choices" in the schema).

[Yoyo Zhou, 2012/07/23 14:25:16]

I believe it's for consistency with pageAction.show/hide -- the other thing they
have in common is no callback.
You could argue that getX should aim for consistency with setX. In my opinion it
would be most consistent if they all took a details object, but since
pageAction.show/hide don't, I'm reluctant to change it.

[not at google - send to devlin, 2012/07/23 14:27:13]

Right you are.

[Jeffrey Yasskin, 2012/07/23 17:00:02]

If it's really _just_ show/hide that are different in this way, I think it'd
make sense to change them to be more consistent. People will eventually stop
writing new page actions, so keeping consistency with them doesn't seem as
important as consistency across the vNext API.

If y'all agree, I'll write a change for this.

+            "minimum": 0,
+            "description": "The id of the tab for which you want to modify the browser action."
+          }
+        ]
+      },
+      {
+        "name": "disable",
+        "type": "function",
+        "description": "Disables the browser action for a tab.",
+        "parameters": [
+          {
+            "type": "integer",
+            "optional": true,
+            "name": "tabId",
+            "minimum": 0,
+            "description": "The id of the tab for which you want to modify the browser action."
+          }
+        ]
       }
     ],
     "events": [