1955433 - Window drag space not working as designed in vertical tabs - toolbar flexible space and drag space become too small or overflow, so as to leave no functional window dragging space

Status: NEW

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

Description

[Nick Rishel [:nrishel]]

For non-maximized windows with horizontal tabs, the upper left hand corner is left unoccupied as to always have a space to drag the window. This space in not present with vertical tabs thus narrow, non-maximized windows need to be expanded before dragging.

Comment 1

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

Hey nrishel,

I believe there are gaps on either side of the URL bar to be draggable in this scenario. Are those available to you?

Also cc'ing sclements, in case there is something else that's meant to be draggable in this configuration.

Comment 2

[Nick Rishel [:nrishel]]

At least in Fx136, for a sufficiently narrow window the gaps on either side of the URL bar are not present. The empty space block - not to be confused with the flexible space - seems to collapse before other UI elements.

Comment 3

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

Hey sclements, do you know what the window-drag story is for the narrow window with vertical tabs case?

Comment 4

[Sarah Clements [:sclements]]

Attachment: Screenshot 2025-03-25 at 10.15.19.png

Have you ever customized the grab space :nrishel? A screenshot would help here with the width of the window and whether you've customized the toolbar area, because I see that you still have a grab space to either side of the sidebar toolbar button even with a narrow window.

Comment 6

[Nick Rishel [:nrishel]]

Attachment: 2025-03-26 13-26-30.mkv

Comment 7

[Nick Rishel [:nrishel]]

I've not customized the drag space. On closer inspection it is there, but it seems to be inconsistent with how much space is reserved, sometimes being functionally unusable. Added a video demonstrating this with a fresh profile.

But I'm assuming we would want a similar button's worth of drag space in the upper-left side of the window similar to normal non-maximized non-vertical tabs windows as a fixed drag point?

Comment 8

[:Gijs (he/him)]

On macOS for me the window drag space and flexible space both scrunch up to 10px horizontal width so there is a ~20px gap to the left of the address bar which can be used, which seems a tiny bit better than the screencast but not exactly "good".

When testing on Windows I see the #vertical-spacer making it into the overflow list, which contributes to the problem - then there is only 10px space from the one spacer that stays in the list (unclear to me why that one stays and the one on the other side of the address bar goes for me - when I retested with about:welcome as in the screencast on nightly, both of them stay, but become small).

The OS difference is likely due to other, unrelated styling differences and minimum width differences on the two platforms. Linux will probably be different still.

Hopefully Yulia can weigh in on what she thinks the expected result is supposed to be here, both in terms of minimum window width, what buttons should/shouldn't overflow in narrow windows (caption buttons, hamburger, extension button, overflow button itself, back/fwd and sidebar button presumably all have to stay... but maybe stop/reload could go - not sure why it doesn't), and where (how much) space is shown.

It's maybe worth noting that the navbar overflow code does not currently have sophisticated logic to prioritize which things overflow. Mostly we can exclude things from overflowing, not dictate in which order things disappear - IIRC we try to drop things off from the end of the toolbar, though we skip so many items that that may not be obvious as a "pattern" to anyone. We could build such logic, of course, though that is more work and it's difficult to see how to do it "correctly" in the presence of potentially arbitrary other widgets (from extensions or the customize palette, and differing user preferences over how "important" each of those widgets might be to them).

Comment 9

[Yulia Popova]

Flexible spaces are customizable and can be removed by the user in Release, Nightly, vertical, and horizontal tab layouts. Both of these flexible spaces disappear when the browser window is resized. The fixed drag space in the horizontal tab layout does not shrink and maintains its size. However, it appears to shrink in the vertical tab layout, becoming notably smaller. Ideally, the draggable space should remain fixed and not shrink.
That said, we recognize that in the vertical tab layout, the toolbar and titlebar merge, causing all icons to be positioned in a single row. Since some icons cannot be placed in the overflow area, the minimum width of the browser window increases. We need to find a balance between maintaining a usable drag space and avoiding a significant increase in the minimum window width. I wonder if we could slightly increase the minimum width of the fixed draggable space, as it currently shrinks down to 10px. Curious to hear your thoughts.

I see the suggestion was made to position the draggable space in the upper-left corner of the window, similar to how it behaves in non-maximized, non-vertical tab windows, as a fixed drag point. The reason we haven’t implemented this as the default position is that it placed the sidebar and the sidebar button too far apart, which led to discoverability issues for the button. Additionally, you can customize the position of the drag space and move it within the toolbar.

Comment 10

[:Gijs (he/him)]

(In reply to Yulia Popova from comment #9)

I wonder if we could slightly increase the minimum width of the fixed draggable space, as it currently shrinks down to 10px. Curious to hear your thoughts.

This seems reasonable. As discussed on slack, the other confusing factor here is that we have a shared min-width for the window (across OSes) but the caption buttons are significantly smaller on macOS so in practice more stuff stays in the toolbar (and there is less shrinking of any flexible spaces) on macOS than on Windows before hitting the minimum window width.

Comment 11

[Nikki Sharpley (:nikkis) (she/her)]

Attachment: Bug 1955433 - Increase vertical-spacer min-width and ensure not overflowable r=#sidebar-reviewers