1366219 - Secondary panels in static hamburger menu should be able to fit longer translations

Status: NEW

(Firefox :: Toolbars and Customization, defect, P5)

Description

[Francesco Lodolo [:flod]]

Attachment: Help subpanel

Based on previous discussions, the main panel in the static hamburger menu adapts in width to fit longer translations.

The problem is that secondary panels don't do that, they remain as large as the main panel, resulting in badly cut items for secondary panels.

You can see an example from the Help panel in the Italian build. The command is barely understandable, there's no tooltip or visual animation to show the rest of the label.

The menu does adapt in height (e.g. open the Developer Tools command), so I'm not sure why it can't adapt in width. Alternatively, it would be great to allow line wrapping in secondary panels.

Comment 1

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #0)
> Created attachment 8869394 [details]
> Help subpanel
> 
> Based on previous discussions, the main panel in the static hamburger menu
> adapts in width to fit longer translations.
> 
> The problem is that secondary panels don't do that, they remain as large as
> the main panel, resulting in badly cut items for secondary panels.
> 
> You can see an example from the Help panel in the Italian build. The command
> is barely understandable, there's no tooltip or visual animation to show the
> rest of the label.
> 
> The menu does adapt in height (e.g. open the Developer Tools command), so
> I'm not sure why it can't adapt in width.

Because it looks like crap if you animate width and height at the same time, while displaying both views, because text starts wrapping/unwrapping/cropping/uncropping mid-animation.

> Alternatively, it would be great
> to allow line wrapping in secondary panels.

Line wrapping is painful and seems to require performance compromises, see bug 1364738, bug 1009116.

I don't really understand though - there is even less space in the current help subview pre-Photon, given that some of the space is taken up by the 'go back' overlap area thingy. Doesn't that have the same problem?

Comment 2

[Francesco Lodolo [:flod]]

> Because it looks like crap if you animate width and height at the same time,
> while displaying both views, because text starts
> wrapping/unwrapping/cropping/uncropping mid-animation.

Right, I think I've seen that with the first iteration of the Other secondary panel.

> I don't really understand though - there is even less space in the current
> help subview pre-Photon, given that some of the space is taken up by the 'go
> back' overlap area thingy. Doesn't that have the same problem?

Yes, but that's only one of the issues in that system, and I gave up trying to fix them. 
Since we're building a new system, I really hope we can embed more flexibility into it.

For the original hamburger menu I've asked for a "localizable" width, but that wasn't an option with the grid of icons (too complex). Is it off the table with the new menu?

Comment 3

[:Paolo Amadini]

For what it's worth, as an alternative to a localizable width, with bug 1364115 fixed it should now be possible to use "visibility: hidden" instead of "display: none" for subviews that we would like to use to influence the minimum width of the panel.

This is easier said than done, so a localizable width might be an easier solution for the moment.

Comment 4

[Francesco Lodolo [:flod]]

Looks like this is hitting us in other panels (Library button).

Comment 5

[Francesco Lodolo [:flod]]

Attachment: bookmark-tools.png

This is French, but Italian is affected as well.