Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Tab Candy : closing last tab of a group leads to an isolated tab

RESOLVED DUPLICATE of bug 586693

Status

Firefox Graveyard
Panorama
P1
normal
RESOLVED DUPLICATE of bug 586693
7 years ago
a year ago

People

(Reporter: Christophe Calvez, Assigned: raymondlee)

Tracking

Trunk
Firefox 4.0b4
Dependency tree / graph

Details

(Whiteboard: [Aug-13-testday])

Attachments

(2 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100812 Minefield/4.0b4pre

a bit similar to bug 577650 - Better handle closing the last visible tab
+ Create two groups; one with a single tab and another with several
tabs. Go into the single tab and then close the tab. You return to the
TabCandy interface as you should, but you see one of the other tabs
zooming out. There should be no zoom out in this case.

Reproducible: Always

Steps to Reproduce:
1. create 2 groups, one with several tabs, one with a single tab
2. go into the single tab, and close the tab

Actual Results:  
The single tab is closed, and a tab from the group is shown. But there is only one visible tab.

Expected Results:  
Switch to the other group, with the other tabs from the group visible.

Going in TabView restores the normal situation.

Updated

7 years ago
Blocks: 586788
(Reporter)

Updated

7 years ago
Whiteboard: [Aug-13-testday][b4]
Version: unspecified → Trunk

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

7 years ago
Priority: -- → P3
(Assignee)

Comment 1

7 years ago
Created attachment 465804 [details] [diff] [review]
v1

V1
Removed some code which is no longer needed and causes problem.  All tests pass without the removed code.  The default behaviour is to return to Tab candy interface when the last visible is closed.
Attachment #465804 - Flags: review?(dolske)
Component: Tabbed Browser → TabCandy
QA Contact: tabbed.browser → tabcandy

Updated

7 years ago
Priority: P3 → P1
Attachment #465804 - Flags: review?(dolske)
Attachment #465804 - Flags: review+
Attachment #465804 - Flags: approval2.0+

Comment 2

7 years ago
http://hg.mozilla.org/mozilla-central/rev/05b4f0fbffcc
Assignee: nobody → raymond
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [Aug-13-testday][b4] → [Aug-13-testday]
Target Milestone: --- → Firefox 4.0b4

Comment 3

7 years ago
backed out http://hg.mozilla.org/mozilla-central/rev/c14d91f2d939
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 4

7 years ago
This seemed to be causing this failure:

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_windowtitle.js | The window title for about:blank is correct (outside private browsing mode) - Got Minefield, expected Minefield Tab Sets

Somehow the tabcandy title is being tracked as the expected title, but it gets correctly reset when switching out of private browsing and fails.
(Assignee)

Comment 5

7 years ago
Created attachment 466028 [details] [diff] [review]
v2

Since TabClose event is fired when a tab is closing, we are uncertain that when the tab is actually removed. The 1ms delay wasn't enough so it's increased to 5ms for checking number of tabs in the same group.  Ideally, a TabClosed event should be introduced so we know exactly when a tab is closed.
Attachment #466028 - Flags: review?(dolske)
(Assignee)

Updated

7 years ago
Attachment #465804 - Attachment is obsolete: true

Comment 6

7 years ago
Raymond, this is probably related to the tabbrowser changes where when you close the last visible tab, it's going to try to select a nearby tab and make it visible, so that there's always a tab in the tabstrip when possible.

Comment 7

7 years ago
So knowing that, perhaps tabbrowser should expose a way to turn off the behavior of selecting a hidden tab if there are no visible tabs to select.

Dao, is there a good way to tell if the TabSelect from unhiding-after-last-visible-closed vs a plain tab switch?

Comment 8

7 years ago
Oh, sorry nevermind. The ui.js is detecting that the last visible tab is being closed -- TabClose and gBrowser.visibleTabs.length == 1.
blocking2.0: --- → beta4+

Comment 9

7 years ago
Seems fixed by the removal of setTimeouts in bug 586693.
Depends on: 586693
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 586693
Attachment #466028 - Flags: review?(dolske)
Comment on attachment 466028 [details] [diff] [review]
v2

Don't need this patch since 586693 takes care of it.
Attachment #466028 - Attachment is obsolete: true

Comment 12

7 years ago
Duplicate bug, removing blocking.
blocking2.0: beta4+ → ---
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.