Allow moving the extensions button in the customize window
Categories
(Firefox :: Toolbars and Customization, enhancement)
Tracking
()
People
(Reporter: jx99zz, Unassigned)
References
(Blocks 1 open bug)
Details
It does not seem to be possible to move the novel extensions button within the customize toolbar window. To keep consistency throughout the browser, and also to accommodate users that either do not want to have the extensions button present or want it in a different location, it should possible to edit the extensions button from the customize window.
Updated•3 years ago
|
I can confirm this is annoying, the only way to disable the novel extensions button is via extensions.unifiedExtensions.enabled.
![]() |
||
Updated•3 years ago
|
Comment 2•3 years ago
|
||
This is definitely something we want to address and our UX folks are already working on it.
Comment 3•3 years ago
|
||
I am going to mark this bug as a duplicate of Bug 1805924 because fixing Bug 1805924 will also fix this bug, this is the same problem our UX team needs to address.
Comment 4•3 years ago
|
||
Actually, I think this is a different proposal, which raises the question of NOT displaying the Extensions button in a fixed position on the toolbar. Some users have mentioned that they keep a frequently used button next to the menu button and having the Extensions button fixed to that spot breaks their workflow.
And for cross-reference on the idea of being able to move the button completely off the toolbar: https://connect.mozilla.org/t5/ideas/please-let-us-move-the-new-extensions-button-into-the-overflow/idi-p/22979 (That obviously raises questions about how users could be notified that an extension needs permissions if the button is not constantly visible.)
Updated•2 years ago
|
Comment 6•2 years ago
•
|
||
(In reply to jscher2000 from comment #4)
And for cross-reference on the idea of being able to move the button completely off the toolbar: https://connect.mozilla.org/t5/ideas/please-let-us-move-the-new-extensions-button-into-the-overflow/idi-p/22979 (That obviously raises questions about how users could be notified that an extension needs permissions if the button is not constantly visible.)
There are some other popup panels that normally anchor to one button, but can anchor to another button (one that is still permanent) as a backup in case the intended anchor is not visible. I believe this is the case with the panel opened by the FxA profile toolbar button? Our CFRPageActions module has this ability too. Could that work?
I think, because there is an Add-ons & Themes button in the app menu, using the app menu button as a backup anchor would be a logical choice. But I guess that may be a product decision, since allowing the user to remove the extensions button means allowing less technical users to trap themselves in a situation where they can't manually pull up the site-specific functionality exposed in the unified extensions panel. IOW, they'd only be able to interact with it when prompted. That's when it's most important, so it doesn't seem like the end of the world, but maybe something worth considering depending on how many other functions are expected to be added to the little addon submenu (gear icon), how easy it's gonna be to bypass all of this to give an add-on all_urls
permissions, etc.
Description
•