Opening new tab causes unnecessary tab overflow widget if New Tab button isn't placed right after tabs




8 years ago
2 years ago


(Reporter: limi, Unassigned)


(Blocks 1 bug, {testcase-wanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Snappy])


(1 attachment)

On my setup (8 app tabs), I get the following behavior shown in the attached movie, where the tab overflow scroll button shows up for an instant before the tab is rendered, which causes the animation to not be as smooth as it should be, since it animates twice.

Slow down the video if you can't see it the first time (I show it twice).
I just tried reproducing this on Windows 7 and OS X, with various window widths, various numbers of app tabs, and various combinations of having Aaptabs and Easy App Tabs installed/uninstalled/enabled/disabled, and I never saw this.

Dão, any idea what's going on?
Alex, can you reproduce this on a fresh profile too?
I can reproduce this when customizing the new-tab button away, don't know why it's happening.
OS: Mac OS X → All
Hardware: x86 → All
Duplicate of this bug: 650492
This could be something related with aero. It had ever happened on Firefox 3.6 when I tested about one year ago with AeroBuddy -
I can reproduce this without glass, and on Linux.
I can reproduce this now with OS X with certain toolbar configurations and window widths, but I still don't know what is actually happening.
I have the same issue on WinXP and Win7-x64, default theme (and, from memory on Linux (Porteus/Slax/Slax-remix). I traced it down to the Tab Utilities addon but it has not been corroborated in their support thread on Mozillazine. 

It only happens once there are enough tabs to fill the tab bar and the tabs automatically resize themselves to fit. Once the tabs become small enough not to be able to resize then the scroll button becomes permanent and the issue goes away.

You also see the same issue when closing the right-most tab but not the left or any of the middle tabs.
I confirm Dão Gottwald comment. You can trigger the bug on a new profile every time you remove the new tab button from the right of the tab bar (either put the button to the left of the bar, remove it or put it in the normal button area). It happens as soon as you have enough tabs open so they start resizing themselves to fit the tab bar and you then close the right-most tab.

My comment about Tab Utilities is invalid. I think there is a bug in the TU code but all that did was expose the underlying Ff bug.
I don't think this is a regression. It happened in Firefox 3.6 if you enable the glass effect and hide the new tab button. In Fx4+ it is just much easier to satisfy these two conditions.
Steps to reproduce:
1. Create a new profile
2. Customize the tabs toolbar and move the New Tab button away
3. Open enough tabs to make the tab bar full (but not overflown)
4. Ctrl+T to open a new tab

Actual result: 
The overflow scroll buttons show up for an instant. 

The problem also happens if you close the right-most tab in step 4. The problem won't happen if browser.tabs.animate is set to false.

Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
Just to confirm, it happens to me on PC's with these build ID's:

Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0

Until this morning the XP PC running 7.0.1 was running 6.0.2 when it upgraded itself. The bug also showed when it was running 6.0.2.

Steps to reproduce are as ithinc's but I usually noticed it closing the right-most tab by middle clicking on it or clicking on the tab's close button
I have verified this issue on Windows 7 x86, on several older releases and it seems to reproduce on all of them to 4.0 (including). The reproduce the issue I used the steps in comment #13.

Regression window:
Last good nightly: 2010-11-18
First bad nightly: 2010-11-19

I see nothing suspicious in
Somebody will probably have to bisect this further.
I can eproduce.

And I try to find regression window with following condition.
* On windows7 classic
* Make browser window width =976px(maybe depend on window border width)
* Open 8 tabs
* Follow the steps in comment #13.

Regression window (Overflow scroll buttons appear and disappear immediately whwn OPEN a new tab)
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100611 Minefield/3.7a6pre ID:20100614002435
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100611 Minefield/3.7a6pre ID:20100614014001
9d9078188333	Dão Gottwald — Bug 543206 - Tab opening animation. r=gavin

Regression window (Overflow scroll buttons appear and disappear immediately whwn CLOSE right most tab)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre ID:20100806235707
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100807 Minefield/4.0b4pre ID:20100807040603
06b0aaa3623b	Dão Gottwald — Bug 380960 - Implement closing tabs animation. r=fyan,gavin

Both regression is caused by implementation of tab animation.
Well, that's not a useful regression range, since we know that browser.tabs.animate=false prevents the bug.
(In reply to Dão Gottwald [:dao] from comment #18)
> Well, that's not a useful regression range, since we know that
> browser.tabs.animate=false prevents the bug.

So, it is impossible to find regression range without testcase.xul.
Yeah, a reduced testcase would be useful in case this is a Gecko bug.
Keywords: testcase-wanted
Duplicate of this bug: 722056
Duplicate of this bug: 728548
From the duped Bug 728548:

The overflow widget is also shown when closing the last tab.

Additionally, when closing the last tab, the tabs are resizing while the mouse pointer does not move after clicking the close-tab button. Closing any other but the last tab does not cause the tabs to resize. 

The resizing is also not completely done, it stops in the middle of the process. It stops when the overflow widget disappears.


What happens if closing the leftmost tab via the close-button
2. the new second-leftmost tab is selected
3. the closing tab is fading out while the other tabs are resizing and pushing the closing tab to the right
4. the closing tab is not visible anymore, the other tabs have not fully resized yet
5. overflow widget appears.
6. tabs continue resizing until they completely fit between the overflow widgets.
7. when the tabs finished resizing, the overflow widget disappears.
8. nothing happens. (the mouse pointer, which did not move but which which was first over the close-button, then over the tab bar, then over the overflow widget, is now over the tab bar again)
9. now move the mouse pointer
10. rest of tab resizing happens.

what happens if pressing strg-t:
1. old tab is deselected
2. overflow widget appears
3. new tab fades in
4. before the new tab has its full size, overflow widget disappears
5. new tab gets its full size
Still happens in both Nightly and UX-Nightly (after customizing away the 'new tab' button.)
Whiteboard: [Snappy]
Duplicate of this bug: 1199222
Summary: Opening new tab causes unnecessary tab overflow widget → Opening new tab causes unnecessary tab overflow widget if New Tab button isn't placed right after tabs
I can reproduce this issue on  	Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Only when the "Open New Tab Button" has been removed from the toolbar.
You need to log in before you can comment on or make changes to this bug.