Implement initial chrome.browserAction.openPopup API.

chrome/common/extensions/api/browser_action.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.
 
 [
   {
     "namespace": "browserAction",
     "description": "Use browser actions to put icons in the main Google Chrome toolbar, to the right of the address bar. In addition to its <a href='#icon'>icon</a>, a browser action can also have a <a href='#tooltip'>tooltip</a>, a <a href='#badge'>badge</a>, and a <a href = '#popups'>popup</a>.",
     "types": [
       {
@@ skipping 292 matching lines @@
         "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."
           }
         ]
+      },
+      {
+        "name": "openPopup",
+        "type": "function",
+        "description": "Opens the extension popup window without a user action. The popup will be from the usual location if the button is not hidden and anchored from the settings button otherwise.",

[Finnur, 2013/10/15 10:44:21]

nit: Is that "anchored" or "anchor ed"?

More importantly: We've discussed the problems with anchoring this off of the
hotdog menu. It seems that the API proposal said "this decision needs to be
revisited before this reaches beta/stable". Who is in charge of that and what's
the plan there?

[justinlin, 2013/10/16 07:06:48]

Ha, it is "anchored" in the code. Not sure why codereview decides to break the
line like that.

Updated the comment as well. Punting on the hotdog popup for now. Looking
through the code, it doesn't seem like a trivial change, so probably better to
do it separately.

[Finnur, 2013/10/16 15:01:26]

I asked not to prompt you to do it in this changelist but to see how you see it
pan out. Are you going to be tackling that? I'm not too bothered if only Cast is
using this API, but if others get a chance to use it then this perhaps becomes a
bigger issue.

But, just to be sure: Does your CL work if you run showPopup against a browser
action that is in the overflow bucket?

[justinlin, 2013/10/16 19:31:29]

Yes, I can tackle them or maybe someone on my team if we decide to move forward
to stable. I believe there's a launch bug for it with needed approvals. Yup, it
works if it's in the overflow bucket. Adding test for that.

+        "nodoc": true,
+        "parameters": [
+          {
+            "type": "function",
+            "name": "callback",
+            "parameters": [
+              {
+                "name": "popupView",
+                "type": "object",
+                "additionalProperties": { "type": "any" }
+              }
+            ]

[Finnur, 2013/10/15 10:44:21]

Is it necessary to return the view here? Is this a problem if we go to a wider
audience with this API?

Matt, what do you think?

[Matt Perry, 2013/10/15 21:29:41]

Should be fine. Extensions can already get the popup using
chrome.runtime.getViews().

[Finnur, 2013/10/16 15:01:26]

Yeah. Minor short-circuit in my brain. For a minute I thought an extension could
use this to get at *other* extensions' popups. But that's not the case here.

+          }
+        ]
       }
     ],
     "events": [
       {
         "name": "onClicked",
         "type": "function",
         "description": "Fired when a browser action icon is clicked.  This event will not fire if the browser action has a popup.",
         "parameters": [
           {
             "name": "tab",
             "$ref": "tabs.Tab"
           }
         ]
       }
     ]
   }
 ]