1982570 - occasionally huge gap in tabbar

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Sören Hentzschel]

Attachment: screenshot

Unfortunately, I don't have any steps to reproduce this. But this is the second time in a few days that the tab bar has had a huge gap at the end that can be scrolled as if there were tabs there. Please see the attached screenshot and the following video:

https://www.youtube.com/watch?v=SQ4_6WbRDfY

A restart of Firefox solved the issue. Tested with Firefox Nightly 143.0a1 (2025-08-11) on macOS 15.5.

Comment 1

[Sören Hentzschel]

Attachment: screenshot

With Firefox Nightly 143.0a1 (2025-08-13) it happened twice more today. It looks as if this gap is getting bigger and bigger with increasing use. When I look at the gap with the inspector tool, it is the element with the ID #tabbrowser-arrowscrollbox-periphery.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Stephen, is this possibly related to some of your recent changes in this area?

Comment 3

[Stephen Thompson [:sthompson]]

Bug 1970664 affecting 142 started setting style="margin-inline-start: ..." on #tabbrowser-arrowscrollbox-periphery in order to make room for the dragged tab(s) to be dropped to the end of the tab strip when the tab strip is overflowing. But I'm confused about the second screenshot because it shows no "style" set on the periphery element, yet the element has a width.

When the tab strip is overflowing, the contents of the #tabbrowser-arrowscrollbox-periphery should only be elements that are hidden, so the element will be taking up 0 width. 228px is 3 times the default tab min width of 76px, so if it was possible that there were 3 (invisible?) tabs inside of the #tabbrowser-arrowscrollbox-periphery, then it would have that width value.

I'm having trouble reproducing this on 143.0a1 (2025-08-14). I'm mainly trying multi-tab drag-drop operations, but if the cause is something else, then I'm not sure what it would be.

Pinging :nsharpley to see if she has any insights. I don't think there's any code that would put things into the main scrollbox periphery. We had recent discussions in bug 1981507 about the pinned tabs periphery and how that was being counted among the tabs, but I can't think of how the unpinned tabs periphery would get tabs inside of it. Not sure how else to explain the presentation of the bug.

Comment 4

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

Bug 1970664 affecting 142 started setting style="margin-inline-start: ..." on #tabbrowser-arrowscrollbox-periphery in order to make room for the dragged tab(s) to be dropped to the end of the tab strip when the tab strip is overflowing. But I'm confused about the second screenshot because it shows no "style" set on the periphery element, yet the element has a width.

That was my first thought, but the screenshot doesn't show the inline style on #tabbrowser-arrowscrollbox-periphery so I think we can eliminate that as the bug...

When the tab strip is overflowing, the contents of the #tabbrowser-arrowscrollbox-periphery should only be elements that are hidden, so the element will be taking up 0 width. 228px is 3 times the default tab min width of 76px, so if it was possible that there were 3 (invisible?) tabs inside of the #tabbrowser-arrowscrollbox-periphery, then it would have that width value.

This is an interesting thought! Sören, if you're able to reproduce again could you please take a screenshot of the browser toolbox with the #tabbrowser-arrowscrollbox-periphery element expanded?

I've tried numerous ways to reproduce this but haven't been able to on 142 or 143, but did notice sometimes when closing tabs in the overflowing #tabbrowser-arrowscrollbox-periphery that there was a lag before the gap left at the end filled - not sure if that's related.

Comment 5

[Sören Hentzschel]

Attachment: screenshot

It's the .closing-tabs-spacer element within #tabbrowser-arrowscrollbox-periphery that has width: 228px as inline style - that's exactly the size of the gap. The toolbartabstop element has a width of 0.

I don't know how I triggered the problem last times, but this time (with Firefox Nightly 144.0a1 (2025-08-19)) it happened after I dragged a few tabs down to move them to a new window.

Another observation: Restarting Firefox is not required, just moving any tab fixes the problem.

Comment 6

[Sören Hentzschel]

With the “tab tearing” feature, I was able to reliably reproduce the behavior with mozregression and a copy of my profile. This results in the following regression range:

https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=37783a3d0d3fc3751c8a96c702df7210591bb524&tochange=7c2eaa8e7f7e192b7daeedb77eb8380aab84c9a7

Unfortunately, due to bug 1959047, I am unable to narrow it down further. I hope this will be fixed soon, as I have been unable to narrow down errors for months because of this.

It seems that tab tearing does no longer adjust the size of the tabs, it remains unchanged. After moving a tab to another position, the width of the tabs increases again and the gap disappears.

In the regression range, I noticed the patch from bug 1972897: keepTabSizeLocked and _lockTabSizing sounds suspicious in connection with the symptom that the tab size does no longer change.

Comment 7

[Sören Hentzschel]

Bug 1972897 was uplifted to Firefox 142 and I tested it with Firefox 141, where I was not able to reproduce, and then with Firefox 142, where I was able to reproduce.

Comment 8

[Stephen Thompson [:sthompson]]

Thanks for the additional debugging! Given that .closing-tabs-spacer is taking up space, it must be my patch for bug 1972897 that caused this problem.

This bug would manifest if:

1. the unpinned tab strip is overflowing
2. the unpinned tab strip is scrolled to the end
3. the dragged tab is not the last tab in the tab strip
4. the dragged tab does not have an owner
5. _unlockTabSizing does not get called on drop nor dragend

I can reproduce this by using your reproduction steps to start dragging a tab from one window and dropping it in a different window. The closing tabs spacer state is tracked separately on each tab strip. The original window does not receive the drop nor dragend events so the tab sizes stay locked and the closing tabs spacer keeps its width. The closing tabs spacer will increment by 1 tab width every time these bug conditions are met.

Using _lockTabSizing was apparently not quite the right tool. I've been working with Nikki on a patch to avoid _lockTabSizing, and I expect that change to resolve this problem. Sorry for the trouble.

Comment 9

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1972897

Comment 10

[Stephen Thompson [:sthompson]]

I expect the patch for bug 1982933 to resolve this bug. The patch for bug 1982933 is tracking for Release 142.0.1, Beta 143.0b4, Nightly 144.

Comment 11

[Dianna Smith [:diannaS]]

:Sören Hentzschel can you confirm this is fixed for you in the latest nightly? (will re-open if not)

Comment 12

[Sören Hentzschel]

Yes, it's fixed in the latest nightly build. Thank you!