When closing tabs, the focus should return to the last viewed tab

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
7 years ago
6 years ago

People

(Reporter: limweizhong, Unassigned)

Tracking

({ux-efficiency})

12 Branch
x86
All
ux-efficiency
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

Close a tab.


Actual results:

1. There is a global property of the browser window which stores either the owner, ownerTab or "related tab" (at least as specified in addTab) of the current tab, but this is reset to nothing every time the current tab changes. This is used to determine which tab would be focused when the current tab closes.
2. If the above property is nothing, then the focus switches to the tab on the right.


Expected results:

{ // Definitions
Let T be the closing tab.
Let A be some ordering of the tabs, either:
a. by first opened time (when it appeared in the tab bar)
b. by last navigation initiation time (when the page started loading)
c. by last viewed time (as in the ctrlTab previews)
Let O(X) be the owner of tab X.
}
Method of focusing tab after closing T:
1. Always switch to the tab on the *left* of T.
2. Switch to first unclosed tab in A.
5. Switch to O(T). If there isn't any owner, switch to first unclosed tab in A.
6. Assuming the owner relationships form a tree, with child-nodes ordered by A, switch to the last tab in the subtree rooted at T, or if there is none, switch to that of O(T).
  * - you recursively take the last sibling if it exists.

I prefer method 2 with order c, which is currently made available in Tab Mix Plus, under "Events > Tab Closing > Closing Current Tab". I think it should be transferred from TMP to the Firefox main branch.
(Reporter)

Updated

7 years ago
Component: Untriaged → Tabbed Browser
Keywords: ux-efficiency
Duplicate of bug 565570. Depends on bug 578327.
(Reporter)

Comment 2

7 years ago
Hmm but the current behavior is as I mentioned. The most irritating part about it is that if I open tab B from tab A, then I open tab C from tab B, then I close tab C, it returns to tab B (expected), but when I close tab B, it does *not* return to tab A (as predicted by my post above).
(Reporter)

Comment 3

7 years ago
Oh I also found something unexpected. If I open tabs B and then C from A in the background, then I switch to tab C and close it, I do *not* return to tab A or B. instead I get focused on the tab on the right of C.
(Reporter)

Comment 4

7 years ago
From Frank: "To illustrate why, imagine the disorientation of having the first of 20 or even 100 tabs selected, opening a new tab with the new tab button, browsing for a bit, opening some links in new tabs, closing those and their opener, and watching the tab container scroll all the way back to the first tab."

In my opinion, this should really be the behavior, signalling to the user that he's really done browsing the new tabs, and getting him back to the tabs he were at previously. It should be the tab container's responsibility to make this scrolling fast -- which it probably is (but I can't check as I have no minimum tab width).

Updated

6 years ago
OS: Windows XP → All
You need to log in before you can comment on or make changes to this bug.