Toolbar buttons overlap in small windows with vertical tabs
Categories
(Firefox :: Sidebar, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr128 | --- | unaffected |
| firefox131 | --- | unaffected |
| firefox132 | --- | unaffected |
| firefox133 | --- | verified |
People
(Reporter: muffinresearch, Assigned: nsharpley)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [fidefe-sidebar])
Attachments
(6 files)
STR
Running Nightly 133.0a1 (2024-10-06) with vertical Tabs enabled.
On Mac, Windows, or Linux and there are various issues related to z-index at small screen widths.
What happens
Icons are running behind each other and on windows icons are visible in the addressbar. See screenshots for what happens on each platform.
What should happen
Reduced widths should not cause icons to disappear behind other icons (e.g. the extensions icon) or be partly visible.
Updated•1 year ago
|
| Reporter | ||
Comment 1•1 year ago
|
||
| Reporter | ||
Comment 2•1 year ago
|
||
| Reporter | ||
Comment 3•1 year ago
|
||
Comment 4•1 year ago
|
||
This looks to be a follow-up from bug 1899598, I'll take a look
Comment 5•1 year ago
|
||
I wasn't able to reproduce this. CustomizableUI does have resize handling which should spot the need to move things into the overflow menu, so there must be some STR which bypasses it. Can you say more about how you reproduce this? Do you switch to vertical tabs, then resize the window? Or re-start the browser, or add stuff to the toolbar and then switch the pref. etc.
Comment 6•1 year ago
|
||
Ah, never mind. As soon as I clicked the button I got it. I was in mozregression looking at an older build and its the navbar-as-titlebar stuff which is needed to reproduce.
Updated•1 year ago
|
Comment 8•1 year ago
|
||
The #nav-bar is an OverflowableToolbar. There is logic in there which measures all the child elements of the toolbar and calculates the available width for the customization target - the element which contains the customizable toolbar widgets. That part seems to correctly compute the widths - which are much narrower when we are in verticalTabs mode and the necessary spacers and window controls are in the toolbar.
Then there's a #onOverflow method which looks through the toolbar's widgets and keeps moving them into the overflow menu until it all fits. But in this configuration, it runs out of things to remove. The urlbar can't be moved to the overflow, nor can the back, forward, reload button or the extensions button.
There are some media queries which set the width of the urlbar in certain conditions - and establish a base min-width of 310px plus some.
With minimum window and toolbar width of 450px, we can't meet both sets of requirements: the window controls must be visible, the navigation controls must be visible, the urlbar and extensions button must be visible - and yet with our current minimum dimensions the numbers do not add up.
Comment 9•1 year ago
|
||
The next steps here in the short term are to impose a wider minimum width for windows with vertical tabs. Adding the window controls and the spacers to allow the navbar to function as a titlebar means considerably less space for all the other non-removable, non-overflowable stuff in there like the urlbar-container, the extensions button, the navigation controls and the main menu button.
It gets a little tricky writing a selector for root elements where tabs in titlebar is true, but the menubar is hidden and the nav-bar has .browser-titlebar etc. I suspect we can apply the new min-width to any window where verticalTabs is true.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 10•1 year ago
|
||
This is to prevent the overlapping of toolbar items that aren't in overflow.
This fix works on Mac but will need to be checked on Linux and Windows as their
controls are a different size.
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
| bugherder | ||
Comment 13•1 year ago
|
||
The fix doesn't seem to be working on Windows. I still see overlapping buttons in the latest Nightly.
Comment 14•1 year ago
|
||
Nikki's patch fixed it on mac but not windows, on latest Nightly.
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 15•1 year ago
|
||
- follow up patch to increase width on Windows and Linux specifically
Updated•1 year ago
|
Comment 16•1 year ago
|
||
Set release status flags based on info from the regressing bug 1899598
Comment 17•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
Comment 18•1 year ago
|
||
| bugherder | ||
Reproduced the issue on Firefox 133.0a1 (2024-10-07) on macOS 15.0.1 by following the STR from Comment 0.
The issue is fixed on Firefox 133.0a1 (2024-10-27). Tests were performed on macOS 15.0.1, Ubuntu 24.04 and Windows 11.
Description
•