Closed Bug 1583148 Opened 5 years ago Closed 5 years ago

Border on nav bar makes it overflow unexpectedly


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




Firefox 71
71.2 - Sept 16 - 29
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox69 --- unaffected
firefox70 --- unaffected
firefox71 --- fixed


(Reporter: mt, Assigned: dao)


(Depends on 1 open bug, Regression)


(Keywords: regression)


(3 files)

Attached file userChrome.css

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.

Flags: needinfo?(dao+bmo)
Attached file CustomizableUI log

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.

  #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.

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.

I'll close this but leave needinfo in case Dão thinks there's something left to be done here.

Closed: 5 years ago
Resolution: --- → INVALID

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: nobody → dao+bmo
Flags: needinfo?(dao+bmo)
OS: Windows 10 → All
Priority: -- → P1
Hardware: x86_64 → All
Resolution: INVALID → ---
Summary: Missing customized items left of back → Border on nav bar makes it overflow unexpectedly

Interestingly, as opposed to border, padding doesn't seem to break things.

Blocks: 1582943
No longer blocks: 1580538
Keywords: regression
Regressed by: 1580538

(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?

Turns out clientWidth already excludes the border, but not the padding, so we just need to stop subtracting the border width.

Points: --- → 1
Depends on: 1583485
Iteration: --- → 71.2 - Sept 16 - 29
Pushed by
Stop subtracting border widths from clientWidth since it doesn't include borders in the first place. r=Gijs
Blocks: 1571236
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.