1598563 - [meta] Change priority order of things moving into the toolbar overflow panel

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, enhancement, P3)

Description

[Marco Bonardo [:mak]]

Verdi would like to give more space to the urlbar in crowded cases, that means:

1. first shrink spacers
2. then overflow searchbar
3. then overflow right side buttons
4. then overflow the home button

As a side note, some other browsers also remove the forward button in very crowded space, but this is not part of the mock-up, just an observation.

Comment 1

[Marco Bonardo [:mak]]

This could probably be broken down into threee parts:

1. make spacers shrink more aggressively until they disappear, before touching anything else
2. make the search bar (if present) be the first element to be moved into the overflow panel
3. make the urlbar shrink a lot less aggressively

Comment 2

[Harry Twyford]

The issue with making the spacers shrink to nothing is that once the user enters customize view, they are impossible to manipulate. My solution thus far is to remove their min-width but adding a 4px min-width in customize mode. With their border, this makes them appear as thick white lines:

toolbarpaletteitem[place=toolbar][id^=wrapper-customizableui-special-spring],
toolbarspring {
  -moz-box-flex: 1;
  max-width: 112px;
}

:root[customize-entered] toolbarpaletteitem[place=toolbar][id^=wrapper-customizableui-special-spring],
:root[customize-entered] toolbarspring {
  /* At very small window widths, expand the springs slightly so that they
     can be manipulated with the mouse. */
  min-width: 4px;
}

They shrink to nothing at about the same rate as Verdi's spec without the added complexity of actually removing them.

Comment 3

[Marco Bonardo [:mak]]

Agree, we should not remove them, and they should likely retain their aspect of "spacers" in customize mode, so you can likely bump up those 4px a bit.
In customize mode the urlbar can be shrinked a lot, it doesn't have to be readable.

Comment 4

[Harry Twyford]

Attachment: Bug 1598563 - Change priority order of things moving into the toolbar overflow panel. r?dao,Gijs

This patch is slightly more aggressive in shrinking the Urlbar in the ~900-700px range than Verdi's spec. I was already surprised at how un-aggressive the shrinking is in this patch so I thought I'd put it up for review before we make it even less aggressive.

Comment 5

[Harry Twyford]

We decided in the Phabricator thread to meet on Monday to discuss these changes. This probably won't land until mid-next week at the earliest, so I'm changing the iteration.

Comment 7

[Mike de Boer [:mikedeboer]]

• Harry mentioned to start looking buggy Home button overflow behavior (setting n-i to raise your awareness).
• Verdi suggests the following change to mitigate concerns:
  1. first shrink spacers
  2. then overflow right side buttons
  3. then overflow searchbar
  4. then overflow the home button

Comment 8

[Mike de Boer [:mikedeboer]]

(So essentially flip the order of 2. and 3. from comment 0)

Comment 9

[Marco Bonardo [:mak]]

(In reply to Mike de Boer [:mikedeboer] from comment #7)

2. then overflow right side buttons
3. then overflow searchbar

I still agree with Gijs (see previous review comments) that this doesn't seem to have enough benefits vs the cost of managing and maintaining code for different priorities. There is already a system to define overflow priority that is the order of things in the toolbar, and it's fully customizable by the user, plus very simple to maintain. We can play with many other things before priorities.

Apart from the buggy home button overflowing, we should rather evaluate overflows of the action buttons and the zoom indicator, that are inside the urlbar and can easily take up space, and apparently they don't overflow at all.

Comment 10

[Mike de Boer [:mikedeboer]]

(In reply to Marco Bonardo [:mak] from comment #9)

(In reply to Mike de Boer [:mikedeboer] from comment #7)

2. then overflow right side buttons
3. then overflow searchbar

I still agree with Gijs (see previous review comments) that this doesn't seem to have enough benefits vs the cost of managing and maintaining code for different priorities. There is already a system to define overflow priority that is the order of things in the toolbar, and it's fully customizable by the user, plus very simple to maintain. We can play with many other things before priorities.

Apart from the buggy home button overflowing, we should rather evaluate overflows of the action buttons and the zoom indicator, that are inside the urlbar and can easily take up space, and apparently they don't overflow at all.

Good points, thanks! So I definitely agree on an overflow strategy for the action buttons, since that's completely absent at this point. My uneducated guess is that they should just return to the meatballs menu before the URLBar starts shrinking, no? Of course, this'll be informed by UX team input, but throwing it out there for discussion.

Comment 11

[Mike de Boer [:mikedeboer]]

Additionally, considering the validity of Gijs' statement(s), I consider the custom overflow order implementation on hold for now.

Comment 12

[Mike de Boer [:mikedeboer]]

(In reply to Mike de Boer [:mikedeboer] from comment #10)

Good points, thanks! So I definitely agree on an overflow strategy for the action buttons, since that's completely absent at this point. My uneducated guess is that they should just return to the meatballs menu before the URLBar starts shrinking, no? Of course, this'll be informed by UX team input, but throwing it out there for discussion.

Drew, since you did the initial implementation of the action buttons, does this make sense to you? The idea here is that when a certain width threshold of the URLBar is hit - whilst the user is resizing the window, for example - that the action buttons that are visible in the URLBar start flowing back into the meatball menu.
I acknowledge that this adds another state/ mode for the buttons to be, which slightly complicates things when customizing the action buttons whilst their overflowing (inside the menu temporarily), but since that state is trainsent (i.e. not persisted across sessions), I think it may be ok. Thoughts?

Comment 13

[Drew Willcoxon :adw]

That makes sense to me too. iirc it was even discussed back when we first implemented the page actions. There might even be an open bug. As you say, the fact that this state would be transient probably makes this a lot easier to implement than it would be otherwise. It definitely seems doable.

Comment 14

[Drew Willcoxon :adw]

(In reply to Drew Willcoxon :adw from comment #13)

There might even be an open bug.

bug 1401835 :-)

Comment 15

[Harry Twyford]

Clearing ni since I filed bug 1611930. Thanks for linking it, Dao.

Comment 16

[Dão Gottwald [:dao]]

(In reply to Mike de Boer [:mikedeboer] from comment #7)

• Verdi suggests the following change to mitigate concerns:
  1. first shrink spacers
  2. then overflow right side buttons
  3. then overflow searchbar
  4. then overflow the home button

This is what we do now.