Border on nav bar makes it overflow unexpectedly
Categories
(Firefox :: Toolbars and Customization, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | unaffected |
firefox71 | --- | fixed |
People
(Reporter: mt, Assigned: dao)
References
(Depends on 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files)
shows what my toolbar looks like today. Of note, there is a flexible space on the far left that doesn't show (more below). There are also two icons (FxA, FPN) that have been pushed into the overflow menu.
shows the customization view, which shows the flexible space and icons.
Adding new items to the customized view to the left of the back button has no effect. I added another space and a few more flexible spaces, but the back button is the first button always.
I've some customizations to my userChrome.css as well, which is fairly extreme in the sense that I've collapsed the menu bar and tab strip. I'll attach that file. It might be playing into this.
Turning on browser.uiCustomization.debug as advised by Gijs shows 'CustomizableUI: Getting overflow info: target width: 1822; available width: 1682' repeated 10 times. I'll attach that later.
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Comment 2•5 years ago
|
||
It's definitely that userChrome.css hack. I think that the available space is being impinged upon by the minimize/maximize/close buttons. I don't know why that would cause icons on the left to enter the overflow, but that's where they all end up. It's a very nice design aside from that little surprise. I think that I'm willing to take on the cost of dealing with this problem if it comes to that.
Comment 3•5 years ago
|
||
#main-window:not([drawtitle="true"]):not([inFullscreen="true"]) #nav-bar { border-right: 140px solid var(--toolbar-bgcolor); }
Looks like it's this. Though I don't understand off-hand how we still end up with the _target
being bigger - it's a child, and there's no overflow.
Reporter | ||
Comment 4•5 years ago
|
||
OK, thanks to Gijs for being tolerant of my rubbish. I'm going to say that I'm happy with this being closed as INVALID, unless this style tweak is something that you are trying to accommodate.
I've managed to find a workaround that works very nicely for my setup that doesn't involve tweaking the intrinsic size of the toolbar.
Comment 5•5 years ago
|
||
I'll close this but leave needinfo in case Dão thinks there's something left to be done here.
Assignee | ||
Comment 6•5 years ago
|
||
I'm reopening this to figure out why the border is breaking overflow. It shouldn't, the calculations attempt to account for it. This may well be the reason for the other regressions that got reported.
Assignee | ||
Comment 7•5 years ago
|
||
Interestingly, as opposed to border, padding doesn't seem to break things.
Comment 8•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #7)
Interestingly, as opposed to border, padding doesn't seem to break things.
Doesn't the padding become part of the clientWidth
of the toolbar? Is us parsing the width out of the getComputedStyle for the border just broken?
Assignee | ||
Comment 9•5 years ago
|
||
Turns out clientWidth already excludes the border, but not the padding, so we just need to stop subtracting the border width.
Assignee | ||
Comment 10•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•3 years ago
|
Description
•