940418 - Australis: Can't move hamburger button in customization mode

Status: VERIFIED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[Andrew Halberstadt [:ahal]]

When in customization mode, it is not possible to move the hamburger button up beside the tabs (ideally I would like to remove it and use a keyboard shortcut).

I realize this is most likely by design, but I really hope there are plans to re-implement some of the customizability features that were lost with Australis at some point in the future.

Comment 1

[Matthew N. [:MattN]]

(In reply to Andrew Halberstadt [:ahal] from comment #0)
> When in customization mode, it is not possible to move the hamburger button
> up beside the tabs (ideally I would like to remove it and use a keyboard
> shortcut).

It should be easy to remove the icon with an extension or simple userChrome.css file. There is already a keyboard shortcut to open the panel.

> I realize this is most likely by design, but I really hope there are plans
> to re-implement some of the customizability features that were lost with
> Australis at some point in the future.

Somewhat off-topic for this bug, but what customizability are you missing? The old Firefox button was customizable either. This extension may help: https://addons.mozilla.org/en-US/firefox/addon/classicthemerestorer/

Comment 2

[Andrew Halberstadt [:ahal]]

(In reply to Matthew N. [:MattN] (catching up on reviews) from comment #1)
> Somewhat off-topic for this bug, but what customizability are you missing?
> The old Firefox button was customizable either. This extension may help:
> https://addons.mozilla.org/en-US/firefox/addon/classicthemerestorer/

The coupled bookmarks star/menu and not being able to put things in the location bar are two other ones that affect me personally. There are other customizations that don't affect me personally, but for which I've heard others complaining (i.e can't remove location bar, tabs must be on top, can't move back/forward buttons).

I know and agree with the motivations behind these changes, but I wish there was some way we could eliminate footguns for less experienced users without annoying our most dedicated ones (which are a small but vocal minority).

Comment 3

[BuTaMuH]

I also would like the icon to be movable.

And on the topic about missing customizations:

I have two habits, that I really don't want to change:

1. For a long time the firefox button was in the upper left corner of the browser window. So for every action I want to do (browsing the history, opening the option window, ... etc.) I moved my mouse to the upper left corner.
 - I guess movable hamburger button will resolve this.

2. Just under the firefox button I used to have bookmark list button. 
 - I think an option if not to separate, at least to swap the coupled bookmarks star/menu button (so that the star is on the right side) will be good too.

Comment 4

[Mike de Boer [:mikedeboer]]

This is by design. Onward discussion can take place on the other communication channels, like the firefox-dev mailing list. Please note that this list is moderated.

Comment 7

[p_mccarthy]

The earlier button could be removed by customization and in fact I was doing so up until about two weeks ago.  The add-on "classic theme restorer" referred to as a possible fix doesn't help this problem at all.  Furthermore, even though I uninstalled the mozilla maintenance service, nightly insists on updating itself and I have to keep reinstalling from an earlier file.  I tried the hamburger button feature and the menu of buttons takes more work to use than simply putting the buttons you want on a toolbar.

Comment 15

[Zack Weinberg (:zwol)]

Nine duplicates of a feature request is enough that a decision not to provide that feature should be reconsidered.  Reopening.

Comment 17

[:Gijs (he/him)]

(In reply to Zack Weinberg (:zwol) from comment #15)
> Nine duplicates of a feature request is enough that a decision not to
> provide that feature should be reconsidered.  Reopening.

That really isn't how this works, or bug 25537 would have been fixed a loooong time ago.

There are good reasons why the button isn't movable (namely: predictability and users not getting "stuck" if they accidentally move or remove it), and adding options for this "for power users" very significantly complicates maintenance (the button is currently outside the areas where buttons can be moved, too, and so it would require some non-trivial DOM fu and JS to make the option work correctly, plus the relevant styling work (the button currently obeys fitts' law on Windows, and so it gets different padding etc. than other buttons, plus the separator, plus the fact that it has an extra container, ...)).

I don't think the benefits of making this movable in core code (as opposed to an add-on, which has already been done!) are worth the effort. Some of this discussion was already had in fx-dev, and reopening this just because there's 10/15/20 other people who were surprised they couldn't move it isn't the right way to go. 

Please write to fx-dev and see if you can get people on board with actual reasons as to why this is necessary, and why our reasons not to do this are wrong. Until that time, let's keep this bug closed.

Comment 19

[Floyd Mån]

(In reply to Matthew N. [:MattN] (away May 9 - 12) from comment #1)

> There is already a keyboard shortcut to open the panel.

Which one is it? I didn't find the shortcut on Mac OS X.

Comment 20

[Dão Gottwald [:dao]]

(In reply to Floyd from comment #19)
> (In reply to Matthew N. [:MattN] (away May 9 - 12) from comment #1)
> 
> > There is already a keyboard shortcut to open the panel.
> 
> Which one is it? I didn't find the shortcut on Mac OS X.

This was an experimental feature that has been removed in bug 946395.

Comment 21

[Pomax]

it's a shame it's that deeply embedded in the UI - the visual presentation in the theme is such that it feels like it should be movable (the anchoring would become unpredictable between different users, I readily admit, but a non-standard look is inherent to customization). thanks for the info though.

Comment 24

[Sebastian Zartner [:sebo]]

In bug 1359016 the argument was to improve the UX by shortening the mouse movements for users who often access the hamburger menu.

(In reply to :Gijs from comment #17)
> There are good reasons why the button isn't movable (namely: predictability
> and users not getting "stuck" if they accidentally move or remove it)

That's definitely an issue, though I'm wondering how big it is. If it's bigger, it might need some UI to help get the button back, if it's smaller some article on SUMO explaining how to get it back might be enough.
Did you make a user research regarding this back then?

> adding options for this "for power users" very significantly complicates
> maintenance (the button is currently outside the areas where buttons can be
> moved, too, and so it would require some non-trivial DOM fu and JS to make
> the option work correctly, plus the relevant styling work (the button
> currently obeys fitts' law on Windows, and so it gets different padding etc.
> than other buttons, plus the separator, plus the fact that it has an extra
> container, ...)).

If the special handling of the button were removed, the code should actually become a bit simpler.

> I don't think the benefits of making this movable in core code (as opposed
> to an add-on, which has already been done!) are worth the effort.

The argument about add-ons being able to make it movable will be invalid once legacy extensions are not supported anymore, i.e. Firefox 57.

So, given the above, I'd like to get this feature reconsidered.

Sebastian

Comment 25

[:Gijs (he/him)]

(In reply to Sebastian Zartner [:sebo] from comment #24)
> In bug 1359016 the argument was to improve the UX by shortening the mouse
> movements for users who often access the hamburger menu.
> 
> (In reply to :Gijs from comment #17)
> > adding options for this "for power users" very significantly complicates
> > maintenance (the button is currently outside the areas where buttons can be
> > moved, too, and so it would require some non-trivial DOM fu and JS to make
> > the option work correctly, plus the relevant styling work (the button
> > currently obeys fitts' law on Windows, and so it gets different padding etc.
> > than other buttons, plus the separator, plus the fact that it has an extra
> > container, ...)).
> 
> If the special handling of the button were removed, the code should actually
> become a bit simpler.

You've now said this in several places, but it's wrong. Having a fixed button with specific styling in 1 place is easy (not to mention something that's already implemented). Trying to make that button customizable, but still making it work correctly in all locations, and updating other code that expects the button always to be visible (what happens with update or other notifications if the button is customized away or on a toolbar that's hidden? what happens when add-on buttons are in the corresponding panel and they force opening it - https://hg.mozilla.org/mozilla-central/annotate/8e969cc9aff49f845678cba5b35d9dd8aa340f16/browser/components/extensions/ext-browserAction.js#l208 - where do you anchor the panel when the button isn't present?) or always in the same place (so the anchoring of the panel needs to be dynamic), is going to be a significant amount of work - not "simpler".

> > I don't think the benefits of making this movable in core code (as opposed
> > to an add-on, which has already been done!) are worth the effort.
> 
> The argument about add-ons being able to make it movable will be invalid
> once legacy extensions are not supported anymore, i.e. Firefox 57.

You can still move the button to the other end of the navbar (which was the original request that you referred to in bug 1359016) with userChrome.css.

Comment 26

[Sebastian Zartner [:sebo]]

(In reply to :Gijs from comment #25)
> (In reply to Sebastian Zartner [:sebo] from comment #24)
> > In bug 1359016 the argument was to improve the UX by shortening the mouse
> > movements for users who often access the hamburger menu.
> > 
> > (In reply to :Gijs from comment #17)
> > > adding options for this "for power users" very significantly complicates
> > > maintenance (the button is currently outside the areas where buttons can be
> > > moved, too, and so it would require some non-trivial DOM fu and JS to make
> > > the option work correctly, plus the relevant styling work (the button
> > > currently obeys fitts' law on Windows, and so it gets different padding etc.
> > > than other buttons, plus the separator, plus the fact that it has an extra
> > > container, ...)).
> > 
> > If the special handling of the button were removed, the code should actually
> > become a bit simpler.
> 
> You've now said this in several places, but it's wrong. Having a fixed
> button with specific styling in 1 place is easy (not to mention something
> that's already implemented). Trying to make that button customizable, but
> still making it work correctly in all locations, and updating other code
> that expects the button always to be visible (what happens with update or
> other notifications if the button is customized away or on a toolbar that's
> hidden? what happens when add-on buttons are in the corresponding panel and
> they force opening it -
> https://hg.mozilla.org/mozilla-central/annotate/
> 8e969cc9aff49f845678cba5b35d9dd8aa340f16/browser/components/extensions/ext-
> browserAction.js#l208 - where do you anchor the panel when the button isn't
> present?) or always in the same place (so the anchoring of the panel needs
> to be dynamic), is going to be a significant amount of work - not "simpler".

I assume all those issues are already solved for the other toolbar buttons. Updating code that expects the button always to be visible means to remove the special logic for this one button (and reuse the code used for the other toolbar buttons). With the button not visible, the update badge or other notifications also won't be visible. Of course, if those notifications should still be shown somehow, this would mean to move them somewhere else then.
How is anchoring of the panel solved for other buttons that aren't present?
I didn't say that changing the behavior of the button doesn't mean some work, though the code related to it would still get simpler, as the special handling for it would be removed.

Sebastian

Comment 27

[Dinar]

duplicates: bug 1407973, bug 1418359, bug 1612395 .

Comment 28

[Dinar]

duplicate: bug 1588116
duplicate requesting removing, with several other such bugs linked: bug 947301. ones not already linked here from that other bugs are bug 987093 and bug 995547.

Comment 29

[Dinar]

an idea: allow to add it second time, in addition to the first, this one movable and removable.

Comment 30

[Dinar]

another idea: if the menu is moved or removed, and it is so much important, frequently needed to support new users, then cannot you make it openable from all context menus of firefox?

another thought: seems there is already an easy way to help new users ... : open the old style menu, it is simple, they just need to press alt key. but the mozilla support agents etc may not be themselves comfortable with that old style menu...

Comment 31

[:Gijs (he/him)]

(In reply to Dinar from comment #29)

an idea: allow to add it second time, in addition to the first, this one movable and removable.

I don't see how this solves anything when what most people want is to remove it entirely (or put it in a hidden toolbar) anyway - see e.g. comment #0 in this bug.

(In reply to Dinar from comment #30)

another idea: if the menu is moved or removed, and it is so much important, frequently needed to support new users, then cannot you make it openable from all context menus of firefox?

No.

another thought: seems there is already an easy way to help new users ... : open the old style menu, it is simple, they just need to press alt key.

It is often more cumbersome to find things there, and in any case we are not interested in changing user habits to prefer the old menu rather than the new one. If anything we're moving in the opposite direction.

Comment 32

[Dinar]

(In reply to :Gijs (he/him) from comment #31)

I don't see how this solves anything

it solves positioning it to the place a user wants. for example, what i am doing. several weeks ago, i have come to idea, that since screen is longer horizontally, it is better to have a vertical desktop environment panel, and since most programs used to have menus on the left top corner, top left corner is more comfortable, so i moved all elements of de panel, like clock, main menu, to the top, and by that time i have been using ff with most elements on its panel on right, and several days ago i decided to move them to left, but i have found out that i cannot move main menu and cannot move the button for opening address bar suggestions.

what most people want is to remove it entirely (or put it in a hidden toolbar) anyway - see e.g. comment #0 in this bug.

as far as i have seen, and i browsed all linked bugs here, (and i myself linked some of them as duplicate or related, by comments), there are more duplicates requesting moving than removing. i have now counted them, quickly, and i see there are 6 reports for removing, 13 for moving.

another idea: if the menu is moved or removed, and it is so much important, frequently needed to support new users, then cannot you make it openable from all context menus of firefox?

No.

why? is not it just a rectangle, for purpose of placing it on the screen? context menus already have submenus, which automatically open to left or to right and always open so that they are entirely visible. and the main menu can be considered even more easier, because its submenus do not open on a side, but above main menu.

Comment 33

[Dinar]

(In reply to Dinar from comment #32)

(In reply to :Gijs (he/him) from comment #31)

another idea: if the menu is moved or removed, and it is so much important, frequently needed to support new users, then cannot you make it openable from all context menus of firefox?

No.

why? is not it just a rectangle, for purpose of placing it on the screen?

there is also indication function of main menu icon, putting it context menu maybe difficult, and it would not be immediately visible there.

Comment 34

[:Gijs (he/him)]

(In reply to Dinar from comment #32)

(In reply to :Gijs (he/him) from comment #31)

I don't see how this solves anything

i found out that i cannot move main menu and cannot move the button for opening address bar suggestions.

I don't think duplicating the button "solves" this issue. It'd be a workaround, and it comes with a whole set of other problems.

another idea: if the menu is moved or removed, and it is so much important, frequently needed to support new users, then cannot you make it openable from all context menus of firefox?

No.

why? is not it just a rectangle

Not internally, no. Firefox doesn't work like that - we can't (ie technically cannot) just move arbitrary bits of UI into other bits of UI just because they're both rectangular.