1417627 - Cannot put menus, Back/Forward, and address bar on the same toolbar

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[Yuri Khan]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171112220346

Steps to reproduce:

1. Right-click empty part of the tab bar, enable [x] Menu Bar.
2. Right-click empty part of the tab bar again, select Customize.
3. Attempt to drag the address bar from the main toolbar to the menu bar.
4. Attempt to drag the menus from the menu bar to the main toolbar.
5. Attempt to drag other buttons from the main toolbar to the menu bar and back.


Actual results:

The address bar refuses to leave the main toolbar.
The menus refuse to leave the menu bar.
Most other buttons (except Back, Forward, Overflow menu, Sandwich menu, and List All Tabs menu) can be placed on any toolbar.


Expected results:

I want the menu bar visible at all times because otherwise it appears and disappears each time I press Alt+B to access my bookmarks, and that causes the other toolbars and the current tab content to jerk.

When I enable the menu bar, the actual menus occupy less than half the available space. I want to be able to move the Back/Forward buttons and the address bar to the vacant space in the menu bar, move the most useful extension buttons to the menu bar and tab bar, and hide the main toolbar to conserve space.

Alternatively, I want to be able to drag the menus to the main toolbar. I’m not particularly concerned with how the toolbar is called, as long as I don’t have to have two.

(Alternatively, I will be content if, when the main menu is hidden and the respective toolbar buttons are on any of the visible toolbars, Alt+B pops up the Bookmarks Menu from the button that looks like a Favorite star in a blank space, and Alt+S pops up the History menu from the clock button, and a keyboard shortcut is added to pop up every other toolbar button menu.)

Comment 1

[:Gijs (he/him)]

(In reply to Yuri Khan from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101
> Firefox/58.0
> Build ID: 20171112220346
> 
> Steps to reproduce:
> 
> 1. Right-click empty part of the tab bar, enable [x] Menu Bar.
> 2. Right-click empty part of the tab bar again, select Customize.
> 3. Attempt to drag the address bar from the main toolbar to the menu bar.
> 4. Attempt to drag the menus from the menu bar to the main toolbar.
> 5. Attempt to drag other buttons from the main toolbar to the menu bar and
> back.
> 
> 
> Actual results:
> 
> The address bar refuses to leave the main toolbar.
> The menus refuse to leave the menu bar.
> Most other buttons (except Back, Forward, Overflow menu, Sandwich menu, and
> List All Tabs menu) can be placed on any toolbar.


We specifically limit the customizability of some items because we do not want it to be possible for users to end up in a state where those items are completely inaccessible. This is why the back/forward buttons, url bar and menubar can't be moved out of their containers. It isn't currently technically possible for us to make it possible to move items between toolbars but not allow them to be completely removed. Even if it were, it would then become possible to put items e.g. on the bookmark toolbar and hide the bookmark toolbar, still leading to user confusion about where items are. In pre-Australis versions of Firefox, this repeatedly caused problems for users who lost access to buttons and were unable to find them back. As a result, we made a conscious decision to limit a few crucial items such that they can no longer be arbitrarily moved.

We understand that this causes problems for advanced users who want a maximum amount of customizability, but at this point in time we aren't going to be revisiting that decision.

> (Alternatively, I will be content if, when the main menu is hidden and the
> respective toolbar buttons are on any of the visible toolbars, Alt+B pops up
> the Bookmarks Menu from the button that looks like a Favorite star in a
> blank space, and Alt+S pops up the History menu from the clock button, and a
> keyboard shortcut is added to pop up every other toolbar button menu.)

We're still considering how to improve keyboard accessibility of the toolbars, so we may do this in future, but it'll need some more careful consideration as to how exactly this would work. I've filed bug 1418973 to improve keyboard a11y of the toolbars.

Also, while I'm aware this doesn't directly address your questions/wants, have you considered using sidebars? They already have shortcuts (ctrl-b/ctrl-h for bookmarks/history) and then you wouldn't need to pop up the menu as much...

As originally filed, this is effectively WONTFIX, so I'm closing it.

Comment 2

[Yuri Khan]

> […reasons why my desired configuration cannot be done…]

I’m not buying it.

Let’s say you want the user to always have the URL bar, the back/forward buttons, and at least one of the main menu or the sandwich menu.

Let the user move them freely. Prevent them from hiding the toolbars that contain the URL bar and Back/Forward. If the main menu and sandwich menu are in the same toolbar, prevent hiding that. If they are on different toolbars, let them hide one and protect the other.


> We understand that this causes problems for advanced users who want a maximum amount of customizability

That describes me pretty well. And most of users who choose Firefox above other browsers, too. You are alienating your primary target audience.


> Also, while I'm aware this doesn't directly address your questions/wants, have you considered using sidebars?

Hell *no*.

I have a monitor 1920px wide. I use a tiling window manager to split it into two windows, each 960px wide. I cannot *afford* sidebars.

Comment 3

[:Gijs (he/him)]

(In reply to Yuri Khan from comment #2)
> > […reasons why my desired configuration cannot be done…]
> 
> I’m not buying it.
> 
> Let’s say you want the user to always have the URL bar, the back/forward
> buttons, and at least one of the main menu or the sandwich menu.
> 
> Let the user move them freely. Prevent them from hiding the toolbars that
> contain the URL bar and Back/Forward. If the main menu and sandwich menu are
> in the same toolbar, prevent hiding that. If they are on different toolbars,
> let them hide one and protect the other.

This would require:

- adding custom code for these items that restricts them from being placed in the overflow menu or the palette (ie removed), and UI such that it's obvious to the user why this happens;
- adding custom code that unhides any of the 4 toolbars when any of these items are on them, and UI to explain to the user why this happens;
- UI to enable hiding the main toolbar;
- appropriately disabling UI elements that normally allow unhiding the menubar/bookmarks toolbar when they have elements on them that make the toolbar unhidable (and somehow providing some kind of UI that explains to the user why they suddenly can't do this thing)
- verifying that all those controls actually work when moved elsewhere (we fixed at least 5 different bugs for photon, and still have some other ones open, just because we made the stop/refresh button movable and animated, which meant certain assumptions in other bits of code got broken)
- breaking web control over popup windows (ie the tabstrip would be visible if the location bar was on the tabstrip, even if the webpage requested a window without any other toolbars)
- updating code that determines content frame sizes based on requests through window.open(..., "height=N") to deal with arbitrary toolbars being hidden/unhidden after the window shows up and we determine which widgets are in which toolbar
- updating all our documentation because now the hamburger/sandwich buttons and the main menu might not be where the docs say they are

etc. etc.

This is a very large amount of extra work that would all require UI/UX design, engineering, automated tests, QA testing, documentation -- and the penalty of getting some of it wrong is sec-moderate to sec-crit security issues because you end up with windows without a location bar which prevent a spoofing risk. We've been over this before (bug 940418 and all its many many dupes).

That's a terrible trade-off when the user group it benefits is so small -- even if it is very vocal.

Comment 4

[Yuri Khan]

(In reply to :Gijs from comment #3)

> This would require:
> 
> - adding custom code for these items that restricts them from being placed
> in the overflow menu or the palette (ie removed), and UI such that it's
> obvious to the user why this happens;

Seems pretty easy. Detect if the drop target is one of these locations and do not accept the drag. No other UI necessary.

> - adding custom code that unhides any of the 4 toolbars when any of these
> items are on them, and UI to explain to the user why this happens;

Alternatively, do not accept the drag if the target is a hidden toolbar.

> - UI to enable hiding the main toolbar;

Yes! That’s the whole point of the workflow described in the opening comment: move all useful controls to the menu bar, hide the main toolbar, end up with two toolbars instead of three, have one more row available for tabs. (I could have said “for content” but hey, who am I kidding? Multi-row tab bar was a big part of my workflow, too.)

> - appropriately disabling UI elements that normally allow unhiding the
> menubar/bookmarks toolbar when they have elements on them that make the
> toolbar unhidable (and somehow providing some kind of UI that explains to
> the user why they suddenly can't do this thing)

Not very difficult. Also no UI necessary, although you could add a tooltip “Cannot hide toolbar containing X” if you felt your users were so stupid as not to get it.

> - verifying that all those controls actually work when moved elsewhere (we
> fixed at least 5 different bugs for photon, and still have some other ones
> open, just because we made the stop/refresh button movable and animated,
> which meant certain assumptions in other bits of code got broken)

In other words, exposing and fixing bugs.

> - breaking web control over popup windows (ie the tabstrip would be visible
> if the location bar was on the tabstrip, even if the webpage requested a
> window without any other toolbars)

Well I’m not convinced web pages should even be able to open popup windows and control what parts of UI they have or don’t have. I have always redirected them to tabs since I found Tab Mix Plus.

> - updating code that determines content frame sizes based on requests
> through window.open(..., "height=N") to deal with arbitrary toolbars being
> hidden/unhidden after the window shows up and we determine which widgets are
> in which toolbar

As far as I am concerned, there is nothing that an application such as Firefox can do to change its window size. The window manager controls this, and a tiling window manager will give the application all the space that is available, whether it wants it or not.

Also, see previous item.

> - updating all our documentation because now the hamburger/sandwich buttons
> and the main menu might not be where the docs say they are

One paragraph at the top: “This article assumes default toolbars. If you have customized them, we assume you know what you are doing. But if you forgot, here’s how to reset them.”

> etc. etc.
> 
> This is a very large amount of extra work that would all require UI/UX
> design, engineering, automated tests, QA testing, documentation -- and the
> penalty of getting some of it wrong is sec-moderate to sec-crit security
> issues because you end up with windows without a location bar which prevent
> a spoofing risk. We've been over this before (bug 940418 and all its many
> many dupes).

At that time we had an escape hatch in the form of Classic Theme Restorer.

As of Firefox 57, my only escape hatch is the Developer Tools inspector. Which I’d have to invoke at the start of every session.