(No comment was entered for this change.)

I created a simple design doc with a proposal for the API:

http://code.google.com/p/chromium/wiki/BrowserActions

I like it - any chance of getting the tabId of the currently selected tab as well as the 
windowId?  It would make sense visually for the action to be applied to the tab since it's 
below the 'tab' handle and alongside the URL.

We always struggle with exactly how much information to include in these events. There 
is a spectrum with "only what is necessary to uniquely describe what happened" at one 
end, and "the entire state of the browser" at the other.

Anyway, tabId makes sense. The full window and tab objects might also.

Wasn't our approach to extensions to make it impossible to clutter the main UI? This 
suggestion provides a lot of potential for clutter.

I'd also definitely vote for a permission to allow an extension to mess with the main 
UI at all. And manually getting rid of browser actions I don't want, even if the 
extension insists on them (provided I really need the rest of the extension).

Actually, this does lead towards a less cluttered UI.  Compare with toolstrips.  One 
major problem with toolstrips is that they take away a large chunk of screen real 
estate, even if you only have one button in them.  With this interface, a small 
extension can have a minimal impact on the browser chrome.

In any case, I agree that the user should be able to control what UI is visible.  
Whether it's toolstrips, browser actions, etc.

Agree that UI to manage this on a granular basis is important.

I also had a very interesting comment about this proposal from a friend IRL that you 
should be able to put the browser actions in your bookmarks bar, or you should be able 
to put favorite bookmarks in this area.

I tend to agree, but am fearful of the bookmark manager/sync can of worms again :/. 
Maybe for a v3 :).

Somewhat related to Issue 1656.  (I look forward to the day I can add a Stop button 
next to Reload :)

A few comments on the proposal:

* I'm fine with starting with one. If we decide to add support for multiple browser
actions, we can add a BrowserActions API with breaking BrowserAction (which should be
simple to maintain as a sub-set of that).

* I agree that not declaring icons would be nice. I think we should try it and see
how it performs.

* It'd be nice if the two points above also were true for page-actions (support
PageAction, make declaring the icons optional)

* For consistency with the page actions API, shouldn't BubbleText be called Name?

* Should we have a single method that updates all the properties in one call?

I don't understand this method in the proposal:

 // Set the badge text. To start, this can only be a number.
 void chrome.browserAction.setBadge(int number);

What's a badge?

We want to let people overlay a little number, for unread counts or temperatures, for
example.

In this proposal, why do images have to be pre-specified?

For example, an extension might want to generate an image dynamically (ie. like 
canvas), for example a weather icon which changes continuously depending on cloud 
cover or something.

For this use case, data: URL's should be allowed, and images shouldn't need to be 
pre-defined.

With this, there is no need for the "badge", since that can be implemented by the 
extension if they need it.

It might also be nice to allow icons to have transparency and allow multiple icons, 
which would be alpha-blended together - for example consider an email icon which gets 
a little star added when there is an email - the little star could be an icon by 
itself that's overlayed on the original.

The extension should also be able to hide the button when it's not relevant, or set 
the button to disabled.

drop down menus should be considered, like the existing buttons - many extensions may 
have many functions they would like to combine into a single button.

Also, has the team considered having a common API for browser and page actions, and a 
flag to decide which is which - effectively both are the same, just one is in the 
address bar and the other is in the toolbar.  All other functionality really could be 
the same from the extension developers point of view.

Thanks for the great feedback omattos.

On Sat, Sep 19, 2009 at 5:51 AM,  <omattos@gmail.com> wrote:
> Comment #15 on  issue 22099  by omattos: Implement browser action buttons
> http://code.google.com/p/chromium/issues/detail?id=22099
>
> In this proposal, why do images have to be pre-specified?

They don't *need* to be. Implementation is easier for us if they are, and there may be a performance issue 
specifying them dynamically.

The issue is that we do not generally allow ourselves to parse complex format like PNG, GIF, and JPEG in the 
browser process for stability and security reasons. For normal web pages, this work is always done in the 
renderer.

Things are more complex for extensions, though, since we want to use the images in the browser UI. To work around 
this, we have added a "utility process" that is sandboxed and used at extension install time to decode the images 
into a safer format (BMP) and save them separately. Thereafter, when a developer tries to use the original image 
from his extension, the bmp is used instead.

For page actions, we wanted to try dynamic images, but were concerned about the latency for starting up the 
utility process to lazily decode the image the first time it is used.

All that said, I agree this would be a much more elegant API, so I've updated the doc to propose that we try that 
first and see how bad it is.

> For example, an extension might want to generate an image dynamically (ie.
> like
> canvas), for example a weather icon which changes continuously depending on
> cloud
> cover or something.
>
> For this use case, data: URL's should be allowed, and images shouldn't need
> to be
> pre-defined.

That is a cool idea. Handling data URLs would need to be a different special case. Canvas exports data URLs using 
PNG encoding, so those would need to be decoded in the extension process before sending them off to the browser. 
I've added a section about that.

> With this, there is no need for the "badge", since that can be implemented
> by the
> extension if they need it.

I think having a badge is good, though, since it will lead to consistent presentation of simple counters, which 
is a common use-case.

> It might also be nice to allow icons to have transparency and allow multiple
> icons,
> which would be alpha-blended together - for example consider an email icon
> which gets
> a little star added when there is an email - the little star could be an
> icon by
> itself that's overlayed on the original.

I would prefer to handle this by just having the author have separate icons, or else composite them using canvas 
as you suggested.

> The extension should also be able to hide the button when it's not relevant,
> or set
> the button to disabled.

We want to encourage developers to use page actions for things that are page-specific and browser actions for 
things which are not. That is one reason we've held back on having a disable or hide method for browser actions.

> drop down menus should be considered, like the existing buttons - many
> extensions may
> have many functions they would like to combine into a single button.

There will be a separate proposal for drop downs.  The drop downs will be designed to work well with both 
toolstrips and browser actions.

aa:  Ah - I hadn't thought about the security implications of decoding the images.

Is the aim that these buttons load simultaneously with the main browser window 
(potentially slowing startup), or load afterwards when the extension process has 
started (giving a surprise to the user as the UI adjusts itself)?

If the plan is for them to load when the extension process is started, then couldn't 
the extension process simply decode the image every time?  (ie. do not cache the 
decoded image).  I haven't done any performance tests, but I'd say it's likely that 
decoding an icon size png/jpg image is faster than opening a .bmp file from disk 
(opening a file is probably a couple of disk seeks by itself, and the disk is already 
used heavily during chrome startup).  This would probably simplify implementation as 
well.

By the way, I agree with all your comments above - this is shaping up to be a pretty 
good feature :-)

(No comment was entered for this change.)

omattos: the spot for the buttons should be reserved when the browser window is 
initially created, but the image may be delayed a moment as it is fetched from disk.

You're right that we could just decode the image everytime, but I'd rather not add that 
additional overhead to browser startup.

(No comment was entered for this change.)

I like the concept here.

However, I think that conceptually this is nothing but a permanent PageAction. We already 
built in the concept of Permanent vs. Tab scoped page action types and I think we have an 
opportunity here to reuse a lot of that code.

Specifically, I don't understand why the manifest needs to use different keys here to 
describe the same set of data... Both have an icon and both have tooltips. It seems that 
instead of coming up with a new manifest format and a new parsing function (and new error 
strings, and ...) we should just add the type attribute to the page action manifest and 
take it from there. :)

We can still add an artificial limit to the number of BrowserActions you can have (if 
needed) and just as easily remove it.

Then we can change the LocationBar to just draw the Tab scoped PageActions and add code to 
the Toolbar to draw Permanent PageActions.

Sound reasonable?

Additional benefit: Much easier for the developer to convert the PageAction from Tab 
scoped to Permanent.

The idea of a 'page action' that is permanent seems weird. We could still reuse a lot 
of code if the only difference between the APIs was the name (page_actions vs 
browser_actions), right?

Yup. And there is further opportunity for reuse if we generalize the PageAction class 
to now be:

class ContextualAction {
  enum PAGE_ACTION, BROWSER_ACTION; ...

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=27319 

------------------------------------------------------------------------
r27319 | finnur@chromium.org | 2009-09-25 20:18:46 -0700 (Fri, 25 Sep 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_browser_event_router.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_browser_event_router.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_file_util.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_page_actions_module.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_process_manager.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extensions_service.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extensions_service.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/location_bar_view_gtk.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/location_bar_view_gtk.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.h?r1=27319&r2=27318
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/browser_actions_container.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/browser_actions_container.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/location_bar_view.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/location_bar_view.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/extension.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/extension.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/extension_constants.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/extension_constants.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/extension_unittest.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/page_action.cc?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/page_action.h?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/renderer_resources.grd?r1=27319&r2=27318
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/resources/extension_process_bindings.js?r1=27319&r2=27318
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/samples/print_browser_action
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/samples/print_browser_action/background.html
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/samples/print_browser_action/manifest.json
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/samples/print_browser_action/print_16x16.png

Implement Browser Actions extensions.

Browser Actions are like Page Actions, except they appear next to the Omnibox and are always visible. For details see http://code.google.com/p/chromium/wiki/BrowserActions.

Added a simple browser action sample that adds a Print button to the chrome toolbar (which brings up the Print dialog for the current page).

Removed |type| from PageActions, which is currently ignored and was already removed from the docs.

Each extension can only have 1 browser_action. Each browser action can specify more than one icon, but only the first is used. And no API has been added yet (besides the event definition).

BUG=22099
TEST=Install the sample browser action, navigate to google.com, press the print button. A print dialog should come up.
Review URL: http://codereview.chromium.org/243001
------------------------------------------------------------------------

Marking fixed now that there is a spike feature in place. Creating smaller bugs for 
remainder of work.

What's the update on the extensions UI proposed in the first comment for this issue? I 
really like that design.

The first part is in: If you are an extension developer, you can add browser actions to 
your manifest, similar to how you can add page actions and respond to clicks. Erik Kay 
is close to checking in support for popup menus (hopefully today).

See:
http://code.google.com/p/chromium/wiki/BrowserActions

Initial popups landed.  There are a bunch of issues (features) filed related to browser 
actions that you can check out to track the development of this UI.  Just search for 
area:extensions browser actions

Cool, thanks!

can't find mentioned print-test extension 1-(

Print browser action is in the source tree;
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/samples/pri
nt_browser_action/

BUG: Browser actions, such as the print browser action, appear to the right of the 
bookmarks menu (with the --enable-bookmark-menu flag).

	Capture.PNG 11.3 KB   View   Download

@35: thanks for the report. I've created a new bug for it, here:  bug 23924 .

(No comment was entered for this change.)

Fixing a bulk edit. Looks like the search query was not correct.

(No comment was entered for this change.)