1982942 - Minimum window width setup does not play well with non-overflowable toolbar buttons

Status: NEW

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

Description

[Nick Rishel [:nrishel]]

Attachment: Screenshot-on-2025-07-28-at-23_33_22.png

Similar behavior as seen in Bug 1978280 but with a different root cause. The tweaked sidebar toggle for Vertical Tabs seems to break browser chrome flow, perhaps same issue with other buttons if they contain similar attributes?

Steps to reproduce:

1. Open Firefox in a fresh profile.
2. Enable Vertical Tabs.
3. Disable Vertical Tabs.
4. Close and relaunch Firefox.
5. Narrow the window width to it's minimum size.

Actual results:
The unified extensions button and the overflow menu button partially overlap when the window width is reduced to its’ maximum allowed size.

Expected:
unified extensions button and the overflow menu button don't overlap when the window width is reduced to its’ maximum allowed size.

Comment 1

[:Gijs (he/him)]

Mike, you last changed some of the overflow mechanics a while back for the webextensions button.

My impression is that this stuff just doesn't scale very well.

The vertical tabs case is trying to cater for the caption buttons. There is some OS-specific stuff going on there. Then there's the fact that we need to cater for buttons that are going to refuse to overflow (like the sidebar button from bug 1926979, but I suspect there are others). The current state requires a bunch of duplication, has magic numbers, and is incomplete.

I think we need a better solution here, but it's not 100% clear to me what that looks like. Do you have ideas? We could look for items with overflows=false in the toolbar and try to dynamically add their width to the required minimum width, or something? I feel like if we went that way it might be better to work out the width of the caption buttons and/or other items dynamically as well, which might mean we can omit the duplication for taskbar tab vs vertical tabs...

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1926979

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I'm going to redirect to sclements for now to see if there's any perspective here on the best way forward from our sidebar / vertical tabs team.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Wait - is this just a dupe of bug 1978280 now?

Comment 5

[Dão Gottwald [:dao]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)

Wait - is this just a dupe of bug 1978280 now?

Bug 1978280 only helps taskbar tabs and/or the browser.urlbar.trustPanel.featureGate = true case, the latter of which isn't the default yet. Even when that's the default, while the urlbar min-width will be smaller and so we'll have a bit more breathing room, it won't fundamentally change the situation in the sense that the questions Gijs has raised here would still be open, and it's only a matter of time until we'd run into these issues again. Bug 1984992 is another case btw.

Comment 6

[Dão Gottwald [:dao]]

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

The vertical tabs case is trying to cater for the caption buttons. There is some OS-specific stuff going on there. Then there's the fact that we need to cater for buttons that are going to refuse to overflow (like the sidebar button from bug 1926979, but I suspect there are others). The current state requires a bunch of duplication, has magic numbers, and is incomplete.

I'm slightly refactoring this in bug 1987429. It's still incomplete (e.g. bug 1982574 comment 33) and has magic numbers, but it should be a bit easier to work with.

Comment 7

[Dão Gottwald [:dao]]

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

We could look for items with overflows=false in the toolbar and try to dynamically add their width to the required minimum width, or something? I feel like if we went that way it might be better to work out the width of the caption buttons and/or other items dynamically as well, which might mean we can omit the duplication for taskbar tab vs vertical tabs...

One further complication is that if we prevent windows from shrinking below half of the screen size, we might break window manager features like tiling and snapping, which is why in the last few days I've worked on reducing our min-width, see bug 1982574 and dependents. Seems like we'll want some kind of safeguard to prevent the min-width from getting out of hand.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1926979