STR: 1. you have tab A and B, where A is on the left and B on the right 2. select tab A, ctl+click a link, opening tab C in the middle of tab A and B 3. select tab C 4. close tab C Expected: tab A is selected Actual: tab B is selected note that i'm not saying tab B should *always* be selected. i think tab A should be selected *if* it's the parent of the closing tab.

To cover the case of several intervening tabs, how about "tab A should be selected *if* it's the parent of the closing tab *and if* the tab to the right of the closing tab is not a sibling of the closing tab"? If a sibling tab is to the right of the closing tab, go there; else if a sibling or parent tab is to the left of the closing tab, go there; else if there's an unrelated tab to the right of the closing tab, go there; else .... I think this is the "Tab Kit" extension's "move right except to stay in group" algorithm, FWIW. Works well for me, but maybe too fiddly for general use.

This behavior can only be seen if you open such a new tab in the background. If you switch to it immediately tab A is selected when tab C gets closed.

Dietrich, This is already a dupe of bug 514796 and bug 515717 and was discussed in those two bugs. Though, cc'ing mconnor on this to review.

I don't think this is the same thing as those bugs, actually - this is a very specific case where a "group" of subtabs is created between two other tabs, and then viewed and closed.

From bug 588548 comment 3, I think this should only apply in the single case; once multiple tabs are background-opened, the intent/interaction becomes less clear.

Comment on attachment 467169 [details] [diff] [review] patch >--- /dev/null >+++ b/browser/base/content/test/browser_bug533232.js maybe I should move this to browser_tabs_owner.js...

I know it is bad etiquette, but my tongue is sore from biting it for so long. This is just another example of the mental gymnastics required to anticipate the current tab open/close behaviour. If RELATED tabs ALWAYS opened to the IMMEDIATE right of the current tab and closing ANY tab ALWAYS selected the IMMEDIATE left tab then all confusion disappears. A a <B> : new tab b A b : select tab A A <c> b : new related tab C a C b : select tab C a >C< b : close tab C A b : auto select tab A a b <D> : new tab D a b D <e> : new related tab E a b D <f> e : new related tab F a b d f E : select tab E a b d f >E< : close tab E a b d F : auto select tab F a b d >F< : close tab F a b D : auto select tab D a b >D< : close tab D a B : auto select tab B a >B< : close tab B A : auto select tab A It is simpler to understand and much more predictable. Tabs always open to the right. Closing a tab always moves you to the left, back towards any parent tabs.

Ian, that works as long as I select the end-most tab, but doesn't for: a B c d a B b1 b2 b3 c d a b b1 B2 b3 c d with your heuristic, closing tabs would go: a b B1 b3 c d a B b3 c d A b3 c d I'm not sure that makes sense. Presently, close to right allows us to do the following heuristic: We start opening related tabs: a B c d a B b1 b2 b3 c d a b B1 b2 b3 c d then switch to the first and start closing them: a b B2 b3 c d a b B3 c d a b C d Not sure either method is better, honestly. Anyway, that's why I recommended we keep this bug about a single open in background tab case: a B c d a B b1 c d a b B1 c d a B c d

If we do any parent/related tab actions, we may also want to make a case for those relationships timing out. If closing B1 refocuses B, the reason is that the user deviated from their main task (the parent B) in order to view a link off of that parent (B1), and they closed B1 in order to return to the main task. If the user does many tasks before closing B1 - creating new tabs, opening new windows, etc - the reason for reopening the parent fades because B1 is no longer a short deviation from the main task. What we should avoid is a user coming back to an old series of tabs and not being able to predict which tab will open when one is closed because the context of parent and related tabs has been forgotten.

(In reply to comment #11) > If we do any parent/related tab actions, we may also want to make a case for > those relationships timing out. If closing B1 refocuses B, the reason is that We already do remember parents and change close behaviour in cases where links are opened in new windows (see bug 465673) and this persists across sessions, etc. We haven't seen any problems with users coming back to the tabset and having the behaviour surprise them. I agree that for more-than-one-child-tab that might be the case. Separate bug, though (see bug 578327 or bug 530203) > task. If the user does many tasks before closing B1 - creating new tabs, > opening new windows, etc - the reason for reopening the parent fades because B1 Oh, yes, this bug advocates the same parent/child heuristic we already use, which is that as soon as we change focus off b1, we dispose of the parenting relationship. I would not expect that heuristic to change. I do, however, think that doing it based on timeouts is tricky and brittle.

Comment on attachment 467169 [details] [diff] [review] patch r=mano

Verified fixed Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100906 Firefox/4.0b6pre Thank you for this fix!!