When new tab is opened, close button of inactive tab disappears

VERIFIED FIXED in Firefox 4.0b4

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: Alice0775 White, Assigned: dao)

Tracking

({regression})

Trunk
Firefox 4.0b4
regression
Points:
---
Bug Flags:
in-testsuite ?
in-litmus +

Firefox Tracking Flags

(blocking2.0 beta4+)

Details

(Whiteboard: [in-litmus-bug-week])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre ID:20100812040939
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre ID:20100812040939

When new tab is opened, close button of inactive tab disappears.

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Open New tab


Actual Results:
 close button of inactive tab disappears 

Expected Results:
 close button of inactive tab does not disappear 


Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/139e50f2d7a1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre ID:20100812025518
Fails:
http://hg.mozilla.org/mozilla-central/rev/cdfff833edf9
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre ID:20100812040939
Oushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=139e50f2d7a1&tochange=cdfff833edf9
Candidate bug:
Bug 582116 - Provide a way to show certain tabs and get visible tabs
(Reporter)

Comment 1

8 years ago
adjustTabstrip determine the close button is visible or not,
However, while animation for New Tab, the width of last visible tab(=New Tab) is less than clipwidth.

WORKAROUND
set browser.tabs.animate to false
blocking2.0: --- → ?
(Reporter)

Updated

8 years ago
Duplicate of this bug: 586677
(Reporter)

Updated

8 years ago
Duplicate of this bug: 586691
(Assignee)

Comment 4

8 years ago
Mardak, can you own this?
(Assignee)

Updated

8 years ago
OS: Windows 7 → All
Hardware: x86 → All

Comment 5

8 years ago
So if we can't take the last tab because it might be animating, what tab can we use for sizing? tabstrip width not including pinned tabs / (Number of visible tabs - pinned tabs) ?
(Assignee)

Comment 6

8 years ago
Taking the size of the first visible non-pinned tab is what we did prior to bug 582116, so restoring this should be enough to fix the regression.

Comment 7

8 years ago
But you aren't guaranteed to get a full width tab. You could be opening a new tab from a pinned tab, say ctrl-click a link from your 1 app tab, and the first non-pinned visible tab would be animating from small to wide.
(Assignee)

Comment 8

8 years ago
No, the new tab would be at the end when adjustTabstrip runs.
(Assignee)

Comment 9

8 years ago
Created attachment 466402 [details] [diff] [review]
restore pre-bug 582116 behavior
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #466402 - Flags: review?(gavin.sharp)
Attachment #466402 - Flags: approval2.0?
Blocks b5, if we get this in time for b4 it can go in. I'd want a test run. I also would love a test to keep this from happening again!
blocking2.0: ? → beta5+
Attachment #466402 - Flags: review?(gavin.sharp)
Attachment #466402 - Flags: review+
Attachment #466402 - Flags: approval2.0?
Attachment #466402 - Flags: approval2.0+
blocking2.0: beta5+ → beta4+

Comment 11

8 years ago
http://hg.mozilla.org/mozilla-central/rev/235a99fd59fd
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b4

Comment 12

8 years ago
this path not always work.

1. open few tabs
2. pinned all your tabs
3. open fast 2 tabs with Ctrl+T

result:
from the new tabs open in step 3. the first one lose the close button.

when you open the second tab fast the first tab don't have time to extend to the full width
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 13

8 years ago
to fix the bug from comment 12 you can move the call to tabContainer.adjustTabstrip from addtab to tabContainer._handleNewTab

or

            if (aSkipAnimation ||
                this.tabContainer.getAttribute("overflow") == "true" ||
                !Services.prefs.getBoolPref("browser.tabs.animate")) {
              t.setAttribute("fadein", "true");
              setTimeout(function (tabContainer) {
+               tabContainer.adjustTabstrip();
                tabContainer._handleNewTab(t);
              }, 0, this.tabContainer);
            } else {
              setTimeout(function (tabContainer) {
+               tabContainer.adjustTabstrip();
                if (t.pinned)
                  tabContainer._handleNewTab(t);
                else
                  t.setAttribute("fadein", "true");
              }, 0, this.tabContainer);
            }
(Assignee)

Comment 14

8 years ago
(In reply to comment #12)
> this path not always work.

This patch deals with the regression from bug 582116. What you're seeing is more related to bug 585776.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
(Reporter)

Updated

8 years ago
Duplicate of this bug: 588001

Comment 16

8 years ago
The close tab buttons still disappear from the inactive tabs if the window is not maximized on Mozilla/5.0 (Windows NT 6.0; rv:2.0b5pre) Gecko/20100820 Minefield/4.0b5pre ID:20100820074529
I'm using "Windows Classic" theme.
WFM on comment 0 with Win 6.1 using Windows Classic theme.  

Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100820 Minefield/4.0b5pre Firefox/4.0b4pre ID:20100820074529

If your seeing them disappear after opening too many tabs and it starts to clip the tab width at the default settings, it is expected.
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre

Do we have any test coverage for this code?
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-litmus?
Litmus testcase added:
https://litmus.mozilla.org/show_test.cgi?id=12805
Flags: in-litmus? → in-litmus+
Whiteboard: [in-litmus-bug-week]
You need to log in before you can comment on or make changes to this bug.