Last Comment Bug 242071 - Need someway to enable toolbar button when first added by an addon
: Need someway to enable toolbar button when first added by an addon
Status: NEW
Product: Toolkit
Classification: Components
Component: Toolbars and Toolbar Customization (show other bugs)
: unspecified
: All All
-- enhancement with 10 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: :Gijs
Depends on: 416246
Blocks: 364307
  Show dependency treegraph
Reported: 2004-04-29 05:08 PDT by Bug Filler
Modified: 2014-10-18 07:05 PDT (History)
28 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Bug Filler 2004-04-29 05:08:09 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040428
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040428

Since firefox has customized toolbar buttons, new buttons from extension cannot
be seen by default. The user need to manually 'customize' toolbar after a new
extension installed.

There should be a way to let newly installed toolbar button shown during the
installation process or at the first time firefox starts after a new extension

Reproducible: Always
Steps to Reproduce:
Comment 1 User image Mike Connor [:mconnor] 2004-04-29 10:42:22 PDT
and how would we determine where to place said button?  No matter what 
principles you apply, it's pretty much going to be wrong.
Comment 2 User image Jesse Ruderman 2004-04-29 18:13:59 PDT
This is important for figuring out how to use a new extension.

Mike: It's easier to move a button than it is to hunt for and add it, so even if
Firefox adds the button in the wrong place, it's better than not adding it at all.
Comment 3 User image Bug Filler 2004-04-29 18:45:46 PDT
Expose a standard function which take toolbar id and position (either absolutely
or relatively to a widget id) for adding a new toolbarbutton once
programmatically. At least in mozilla, new button is appended before the
location entry. For now, I have to popup an alert dialog telling users to
customize after a installation.

And I have installed a few other toolbar extension which has no such warning.
Result? After a installation, nothing changed with a restart if I did not look
at the customize palette. Most users have no idea that you can customize a
firefox toolbar.
Comment 4 User image Mike Connor [:mconnor] 2004-04-29 20:41:06 PDT
> Most users have no idea that you can customize a
> firefox toolbar.

therein lies the rub.  If we stick it in the wrong place, how will users know
how to change it?  In Firefox, there's no limitation on where you can have
items.  If its related to a certain function, you could add it next to that
element (i.e. if you have something to convert typed URLs, it would logically go
next to the urlbar element, other buttons are trickier).

I'm not saying we won't do something like this, I'm just saying that it would be
a pain to implement
Comment 5 User image alanjstr 2004-07-19 10:47:01 PDT
I think I prefer the buttons appear, if even on the far right end of the
menubar, so that someone knows there are buttons.  
Comment 6 User image Przemyslaw Bialik 2005-05-10 16:53:57 PDT
PubSub Sidebar extension (0.5.356 tested on FF 1.0.3) - adds automatically its button to the
toolbar. Also it checks if button is showing and if not it re-adds it back. I
would say that if user can customize his toolbar then such action by extension
should be disallowed (allow to show it on install but not force user to disable
the extension if he did not want to see the button e.g. he would use view ->
sidebar to use the extension).
Comment 7 User image Benjamin Smedberg [:bsmedberg] 2005-11-16 13:36:41 PST
Robstrong, I'd love for you to take a look at this... mconnor has been wanting to rewrite the toolbar-customization code, but this may be easier than a total rewrite.
Comment 8 User image Mike Connor [:mconnor] 2005-11-16 15:24:59 PST
The toolbar customization code still does a lot of scary things that I'd like to fix on trunk using importNode, but doing this for 2.0 would be absolutely great.
Comment 9 User image Robert Strong [:rstrong] (use needinfo to contact me) 2005-11-17 14:04:11 PST
If an extension is able to define that it should have a toolbar button on toolbar 'x' after widget 'y' or before/after position 'n' there is still no good way to guarantee that the toolbar / widget / position specified is currently shown or valid. I think something along the lines of the following is a better solution.

Create a new type of toolbar that is displayed on first run after an extension that has toolbar buttons is installed with only the buttons for the newly installed extension shown or possibly all of the buttons for the installed extensions that are not already on other toolbars. The buttons on this toolbar should probably only allow drag and drop of the buttons it has to other toolbars and the toolbar would also have the ability to easily close on the toolbar itself. There would be lots of details to hash out such as how to gaurantee the toolbar isn't displayed multiple times for the same extension, how to best handle upgrades, etc. but I think this is less error prone than trying trying to guarantee what can't be guaranteed. This toolbar could also have the ability to open the help docs to educate users about customizing toolbars.
Comment 10 User image Ray Kiddy 2007-09-15 13:39:31 PDT
I am writing an extension for someone who wants a toolbar button, with a popup in it, added after install. I definitely understand the philosophical point behind the suggestion that having extensions forcibly install buttons is not a good thing. However, these people have customers who would be willing to have this happen. So, does it need to be made technically difficult?

I have also observed that doing the install and then not calling BrowserToolboxCustomizeDone leads to weird behavior. A code snippet on MDC says "If you don't do the following call, funny things happen" ( Really? Like a right-mouse button press anywhere in the window bringing up the popup menu and thereafter stealing all keystrokes? Like going to the Toolbar->Customize menu option and hitting Done causes the entire app to ignore all mouse clicks? Funny things like that? "Funny" is probably not the word I would use. And after calling BrowserToolboxCustomizeDone? Well, different "funny" things are happening.

And, oddly, these problems only appear on Windows. I am used to seeing problems on the Mac only and then, as my ex used to say, "it must suck to be you." I am not used to seeing something work on the Mac and go wonky on XP....
Comment 11 User image Jorge Villalobos [:jorgev] 2008-07-09 13:33:13 PDT
I think most extensions that modify the toolbar either (1) add a new toolbar with multiple items or (2) add a single button that does something completely unrelated to the rest of the buttons in the navigation toolbar.
Under that assumption, here's a suggestion:
- Have an "Add-ons" toolbar, hidden by default, that extensions can overlay. Or maybe have a function call somewhere to add the button by ID. 
- Normally the user would never see this toolbar.
- When a new add-on is installed, and if it adds a button to the Add-ons toolbar, the toolbar appears. Perhaps the navigation toolbar can show some button at the very end that allows to easily toggle it.
- If the user wants, he can move the button to the navigation toolbar and forget about the Add-ons toolbar.

- Users who install lots of extensions will have a single toolbar with icons for all the ones that choose to only add one.
- The navigation bar will be cleaner.
- This approach doesn't depend on adding buttons at a specific position.

- Some developers will refuse to do this because they want their icon with maximum visibility.
- If you only install one extension like this, you'll end up with a whole toolbar and one button in it. Perhaps the first time the toolbar is displayed, Firefox could also show a message suggesting that the button can be moved up, and the toolbar can be hidden.
Comment 12 User image Jonathan Protzenko [:protz] 2010-07-27 13:01:55 PDT
Jorge, while your argument makes perfect sense for Firefox extensions and, given recent screencasts and mockups, does indeed look like the path the Firefox team is taking for the forthcoming versions, what about Thunderbird? There's multiple toolbars in Thunderbird:
- message compose toolbar
- address book toolbar
- mail toolbar (the big one at the top of the main window)
- message toolbar (the small one just on top of a given message)
- and I'm probably forgetting one or two.

I think there's little chance that any of them will ever have a matching "addons toolbar". Plus, toolbars such as the message toolbar are *the* place to add message-related actions. The contents of that toolbar are very consistent, and it feels quite natural for extensions to add buttons there.

Let's imagine an extension that, for RSS messages, adds a "Share on Facebook" button in the message reader toolbar. That extension would definitely need such a mechanism.

So please don't consider this as a WONTFIX. I firmly believe that's still a feature that needs to be implemented.
Comment 13 User image Jorge Villalobos [:jorgev] 2010-07-27 19:19:54 PDT
(In reply to comment #12)
> Jorge, while your argument makes perfect sense for Firefox extensions and,
> given recent screencasts and mockups, does indeed look like the path the
> Firefox team is taking for the forthcoming versions, what about Thunderbird?

You're right, I was only thinking about Firefox when I proposed this. However, I also think that UI and add-on UI hooks are very dependent on the target application, and I doubt that there's a one-size-fits-all solution for all XUL-based applications.

To clarify, my suggestion is for Firefox only, and a different approach should be considered for Thunderbird if there is in fact a number of different reasonable places to add toolbar buttons.
Comment 14 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2012-02-08 04:39:31 PST
Moving to a more appropriate component, since this isn't something the Add-ons Manager can solve.

Note You need to log in before you can comment on or make changes to this bug.