Closed Bug 586666 Opened 14 years ago Closed 14 years ago

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

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b4
Tracking Status
blocking2.0 --- beta4+

People

(Reporter: alice0775, Assigned: dao)

References

Details

(Keywords: regression, Whiteboard: [in-litmus-bug-week])

Attachments

(1 file)

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
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: --- → ?
Mardak, can you own this?
OS: Windows 7 → All
Hardware: x86 → All
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) ?
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.
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.
No, the new tab would be at the end when adjustTabstrip runs.
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+
http://hg.mozilla.org/mozilla-central/rev/235a99fd59fd
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b4
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 → ---
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);
            }
(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
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: