1816707 - Display Add-ons browserAction buttons in the toolbar customize menu

Status: RESOLVED INCOMPLETE

(WebExtensions :: Frontend, enhancement)

Description

[Manuel Reimer]

As this part was lost when my previous bug was marked as duplicate, I want to split out this part of my suggestions.

I already offered my help, but if there is any viable way of having the Add-on buttons back in the toolbar customize dialog, then I would like to help with implementing this. It would make it way easier for users to see which buttons they have available to place to the toolbar.

Just one example where a user of one of my Add-ons was totally lost finding out how he can get the button to display after installing an Add-on which is supposed to be operated with its button: https://github.com/M-Reimer/undoclosetab/issues/38#issuecomment-1425061590

If this is already handled elsewhere, then I'm sorry. I tried to find any bugs suggesting getting browserAction buttons back into the browser customize dialog without success.

Comment 1

[Rob Wu [:robwu]]

( linking the "previous bug" for visibility - bug 1816230 ).

Currently:

• When customization mode is entered, all browser action buttons disappear.
• Outside of customization mode, users can right-click on individual browser action buttons, and then click on "Pin to Toolbar" to move it inside the menu or outside of it.

What functionality are you looking for that is not already covered by bug 1795235?

Comment 2

[William Durand [:willdurand]]

Extension widgets not pinned in a toolbar are no longer listed in customization mode because these extensions are now placed in the extensions panel, which isn't represented in the customization mode.

Extension widgets already pinned in a toolbar (navbar being the default) are visible in the customization mode, like before. From there, it is possible to move the extension widgets, e.g. in other toolbars or to reorder them. It is no longer possible to move these extensions into the overflow menu, though. The reason for this is that the "overflow list" for extensions is the extensions panel.

Comment 3

[Manuel Reimer]

The problem with moving the customizability of toolbar buttons (browserAction) is that the "Extensions" menu is not only for the purpose of quick access to buttons. All extensions are listed there. This includes all those without toolbar buttons or with optional toolbar buttons not needed for the Add-on's functionality. There is no way to hide extensions there to have quick and easy access to the ones with buttons, that I actually need.

The "overflow list" is a customizable list. I can place features there that I occasionally need but don't need regularly. I can even order items there in an order that fits my workflow.

Before	Now
Users had immediate feedback if an Add-on comes with a button or needs one for its functionality. It was immediately added to toolbars.	Add-ons are added without telling the user in any way that a button is needed to operate the Add-on
Add-on buttons could be sorted together with browser built-in buttons in the overflow menu in any order a user likes	The only way to not have Add-ons button functionality in the toolbar is to search for it in a long list every time you use it
One unified way of adding buttons to toolbars	"Customize toolbar" only works for Firefox built-in buttons. Have to use "Pin to Toolbar" from the extensions menu for Add-on buttons
One unified way of removing buttons from toolbars	"Customize toolbar" only works for Firefox built-in buttons. Dragging a Add-on provided button "out of a toolbar" into the "button overview" area of "Customize toolbar" does nothing

To be honest: I'm not sure if Firefox needed "Pin to Toolbar" at all. Better "re-use" existing customizability features. But to make it easier for Chrome users to "feel at home", it maybe is good to have it? Probably the following would work for many Firefox regular users and even make the extensions.unifiedExtensions.enabled preference much less a requirement to be kept.

• Move all browserAction buttons back to the regular toolbar customize feature and make it a "unified toolbar customize UI", again
• Clicking the "Pin to Toolbar" checkbox moves the button from "toolbar customize space" to the toolbar.
• Unclicking mentioned checkbox removes the button from the toolbar but keeps it available in "Customize toolbar".
• Moving the browserAction button to a toolbar in "Customize toolbar" mode causes the "Pin to Toolbar" checkbox to be checked. Removing it from the toolbar unchecks the checkbox.
• Allow to place browserAction buttons to the overflow menu again to give Firefox back some of its power it had when it comes to customizability.
• Maybe add buttons to the toolbar automatically on Add-on installation, again. But this is not that important as users are likely to search for buttons in the "Customize toolbar" mode, anyways.

What I want to discuss here is not about the fact that the new Add-ons button can not be customized. Maybe it is a strong requirement for future Add-on functionality and so is a must-have to be visible. What I want to improve is how cluttered toolbar customization currently feels. It does not feel like good integration of a new requirement but like patching Chrome functionality onto Firefox without integrating it into Firefox typical workflows like toolbar customization.

Comment 4

[Rob Wu [:robwu]]

(In reply to William Durand [:willdurand] from comment #2)

Extension widgets not pinned in a toolbar are no longer listed in customization mode because these extensions are now placed in the extensions panel, which isn't represented in the customization mode.

Given this stated reason, we could support customization if the "content" of the Extensions Panel can somehow be visible in customization mode. This does not even require customization within the Extensions Panel, it could be "inside the panel" vs "outside the panel" (aka not pinned vs pinned). There are multiple ways to do so, e.g.:

• E.g. by toggling its visibility on click (and not auto-close when something else is clicked), then individual extension buttons could be dragged between the toolbar (navbar) and the "Extensions Panel" area. Only extensions with "browser action" buttons can be pinned, so we could hide the rest. I imagine users wanting to hide items in the menu that are not relevant to them, that would be yet another request (part of bug 1795235).
• E.g. as stated in comment 3 by Manuel: render unpinned items in the "toolbar customize space", and pinned items in the toolbar. Items moves off the toolbar are usually hidden, so this approach may raise the question why hidden items reappear in the Extensions Panel.

(the current behavior is: pinned extension buttons can be moved across the toolbar, but not be moved elsewhere/outside of the visible area)

Yet another question is whether the user would be able to customize within the panel (visibility and/or order). I suggest to not block on that decision, since the pin/unpin flow sketched above can be evaluated independently of that.

(In reply to Manuel Reimer from comment #3)

The problem with moving the customizability of toolbar buttons (browserAction) is that the "Extensions" menu is not only for the purpose of quick access to buttons. All extensions are listed there. This includes all those without toolbar buttons or with optional toolbar buttons not needed for the Add-on's functionality. There is no way to hide extensions there to have quick and easy access to the ones with buttons, that I actually need.

Currently there is pinned vs non-pinned. Users can pin extensions to have functionality that needs to be available at all times. It looks like you're looking for a way to say "This unpinned extension has a higher priority and should be rendered above other items". But the bullet list from your comment seems to not offer that level of functionality.

• Maybe add buttons to the toolbar automatically on Add-on installation, again. But this is not that important as users are likely to search for buttons in the "Customize toolbar" mode, anyways.

I don't know whether users will automatically be looking for new buttons in "Customize toolbar", but the concern expressed here is valid: the current post-install experience is not very obvious to users. It is not obvious whether an extension has a button with functionality. Especially since it is not visually obvious whether an item in the Extensions Panel is linked to "browser action" functionality.

At this point it is unclear what this feature request is about. The request in the summary (title of the bug) looks sufficiently distinct from bug 1795235 and potentially actionable. However, there are other miscellaneous concerns/topics touched in comment 3.

Comment 5

[Rob Wu [:robwu]]

Manuel, there was a question at the end of my previous comment (comment 4). Could you clarify?

(In reply to Rob Wu [:robwu] from comment #4)

At this point it is unclear what this feature request is about. The request in the summary (title of the bug) looks sufficiently distinct from bug 1795235 and potentially actionable. However, there are other miscellaneous concerns/topics touched in comment 3.

Comment 6

[Manuel Reimer]

I tried to explain in detail in https://bugzilla.mozilla.org/show_bug.cgi?id=1816707#c3

My request is about somehow integrating Add-on buttons and browser built-in buttons again. In the current state the way how Add-on buttons are handled just feels like they have been "ripped out" of the place where they should be (Toolbar customize mechanism).

Comment 7

[Rob Wu [:robwu]]

Does my interpretation at the start of comment 4 match your intent behind the bug? I tried to identify an actionable engineering task here, but there is a difference between what the bug summary (title) asks and the multiple remarks in comment 3.

Comment 8

[William Durand [:willdurand]]

I am going to close this bug but we can re-open it if you provide more information, thanks!

Comment 9

[Manuel Reimer]

(In reply to Rob Wu [:robwu] from comment #4)

• E.g. as stated in comment 3 by Manuel: render unpinned items in the "toolbar customize space", and pinned items in the toolbar. Items moves off the toolbar are usually hidden, so this approach may raise the question why hidden items reappear in the Extensions Panel.

Actually I don't understand what you mean with "hidden" here.

Currently there is pinned vs non-pinned. Users can pin extensions to have functionality that needs to be available at all times. It looks like you're looking for a way to say "This unpinned extension has a higher priority and should be rendered above other items". But the bullet list from your comment seems to not offer that level of functionality.

This would be covered if it would be possible, again, to place Add-on buttons to the "Overflow Menu".

At this point it is unclear what this feature request is about. The request in the summary (title of the bug) looks sufficiently distinct from bug 1795235 and potentially actionable. However, there are other miscellaneous concerns/topics touched in comment 3.

I at least tried to explain what my issue is. For me it just feels ugly to have two completely different mechanisms to organize Add-on toolbar buttons and Firefox built-in toolbar buttons. Every step in the direction of somehow making those mechanisms more similar, again, would be a step into the right direction.

Or to (at least try) to summarize in one sentence: Make the browser toolbar buttons, provided by Add-ons, behave exactly the same as Firefox built-in buttons. Place them back into the toolbar customize system with all consequences.