242071 - Need someway to enable toolbar button when first added by an addon

Status: NEW

(Toolkit :: Toolbars and Toolbar Customization, enhancement)

Description

[Bug Filler]

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
installed.


Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Connor [:mconnor]]

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

[Jesse Ruderman]

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

[Bug Filler]

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

[Mike Connor [:mconnor]]

> 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

[alanjstr]

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

[Przemyslaw Bialik]

PubSub Sidebar extension (0.5.356 tested on FF 1.0.3) -
http://www.pubsub.com/sidebar_firefox.php 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

[Benjamin Smedberg]

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

[Mike Connor [:mconnor]]

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

[Robert Strong (they/them - no direct email)]

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

[Ray Kiddy]

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" (http://developer.mozilla.org/en/docs/Code_snippets:Toolbar#Adding_button_by_default). 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

[Jorge Villalobos [:jorgev] (he/him)]

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.

Pros:
- 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.

Cons:
- 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

[Jonathan Protzenko [:protz]]

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

[Jorge Villalobos [:jorgev] (he/him)]

(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

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Moving to a more appropriate component, since this isn't something the Add-ons Manager can solve.