1583148 - Border on nav bar makes it overflow unexpectedly

Status: RESOLVED FIXED

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

Description

[Martin Thomson [:mt:]]

Attachment: 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.

Comment 1

[Martin Thomson [:mt:]]

Attachment: CustomizableUI log

Comment 2

[Martin Thomson [:mt:]]

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

[:Gijs (he/him)]

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

Comment 4

[Martin Thomson [:mt:]]

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

[:Gijs (he/him)]

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

Comment 6

[Dão Gottwald [:dao]]

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.

Comment 7

[Dão Gottwald [:dao]]

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

Comment 8

[:Gijs (he/him)]

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

Comment 9

[Dão Gottwald [:dao]]

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

Comment 10

[Dão Gottwald [:dao]]

Attachment: Bug 1583148 - Stop subtracting border widths from clientWidth since it doesn't include borders in the first place. r=gijs

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/03663209ba51
Stop subtracting border widths from clientWidth since it doesn't include borders in the first place. r=Gijs

Comment 13

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/03663209ba51