514796 - Change 'Default' Tab Closing Behavior/Position for Firefox (Closing related tabs should switch to the next related tab (or the parent tab)

Status: VERIFIED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[u88484]

This is basically the opposite of bug 465673 (Change 'Default' Tab Opening Behavior/Position for Firefox).

Closing related tabs should switch to the next related tab (or the parent tab) and not next tab to the right.  The only time the switch should be to the next tab to the right is when the parent tab is closed and no related tabs are left open.

Comment 1

[[not reading bugmail]]

Closing tabs starting with the right most open tab, normally moves to the next tab to the left after the close.  If you close any other tab, it doesn't switch focus to the left tab, but instead moves to the right.  

I think it should move to the left instead, being more logically aligned in relation to having opened tabs from the left.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Just to be sure, does this bug mean: "change the the default value of browser.tabs.insertRelatedAfterCurrent to false" or should bug 465673 be backed out for some reason?

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #2)
> Just to be sure, does this bug mean: "change the the default value of
> browser.tabs.insertRelatedAfterCurrent to false" or should bug 465673 be backed
> out for some reason?

No, turning off that pref reverts to the old open behavior where it opens at the end of the tab bar, so appears to have nothing to do with closing tabs.

There is no need to back out, it just needs some refinement to be truly 'parity' with IE8 and Chrome.

Comment 4

[Dão Gottwald [:dao]]

Two ways to address this:
change tab ownership handling (i.e. make this a duplicate of one of the bugs in <https://bugzilla.mozilla.org/showdependencytree.cgi?id=345028&hide_resolved=1>) or toggle browser.tabs.loadInBackground so that we don't reset the owner.

Comment 5

[u88484]

Dao, just to be clear you mean changing browser.tabs.loadInBackground to false by default?

If we did that then I would think that tabs opening relative is technically pointless then.  If new tabs aren't loading in the background then the user will read through that tab, close it and move back to the original tab to open a new one and so on.

With this preferences as true, users are able to for instance read CNN while middle+clicking or ctrl+clicking to open a bunch of new tabs while still staying on CNN to open more and more tabs to read through them later without having to switch back and forth between the news stories and the main CNN page to continue opening more tabs.

I vote for the change to tab ownership handling and reading the title of the bugs you linked seem to agree with what I filed this bug about.  Now the question is, is any work going to done with changing the tab ownership handling?  If we change how new tabs are opening then we should also change how tabs close be the reverse of how they were opened hence my comment 0 saying this is basically a reverse of bug 465673.

Just to ask, we can't just basically use the patch in 465673 and do the reverse for closing tabs?

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

I think that this is a WONTFIX for the same reasons we didn't implement complex parenting schemes back in Firefox 2.

From a system perspective, our goal should be to match user expectations. It's hard to predict expectations once users start opening tabs from pages which were opened from other pages, let alone once they then start switching between those tabs and potentially re-ordering them. 

From a user perspective, the need is to be able to predict what will happen when you close a tab. It's hard for people to remember where tabs came from, and so having the close operation jump unexpectedly between tabs on the tabstrip will likely be quite surprising and unpredictable.

The current parenting rules are simple by design: if a new tab A' is opened from a link from tab A, and no other action is taken, closing tab A' brings the user back to tab A. In all other cases, we close to the right, which is predictable.

Comment 7

[Martijn Wargers (dead)]

Not at all. Current state is not predictable to me. Fixing this bug, would fix the unpredictability for me.

Comment 8

[[not reading bugmail]]

I believe Kurt filed this bug in relation to having the Default behavior tabs pref turned on.  Though if the old tab behavior is on, this makes sense.  But now the behavior varies.  If you turn on Switch to tab immediately, the tab focus goes to the left.  Now it goes to the left and right depending on which tab or what setting you have turned on/off.

Comment 9

[Jim Jeffery not reading bug-mail 1/2/11]

This needs reconsideration.  The way it sits now is no way near 'parity' with IE8 or Chrome.  Both return to the parent tab no matter if you switch to another tab and come back, it always eventually if you have a lot of tabs you opened from the parent, come back to parent.  

I have already encountered times when I ended up closing the 'parent' tab by mistake, and if it happens to me, an experienced user, what is 'gramma' going to think ?

Comment 10

[WildcatRay]

Just adding my $0.02. The decision to WONTFIX this seems a bit hasty given that IE8 goes so far as to color the parent and child tabs the same to set them apart from the other tabs. "WONTFIXing" this is to concede this feature to IE and can lead to the impression that Firefox is an inferior browser in the eyes of "average" users.

Comment 11

[[not reading bugmail]]

A couple notes.  We need a real rundown behavior comparison.  Did IE8 add back to parent closing? because I don't see it in IE7.  

Also, fixing bug 514310 also added some more fun to the mix.  

And why 'switch to new tab immediately' added special close behavior is not understood, and I cannot find the bug #.  The full behavior of that option doesn't reflect the UI text for the preference.  

IE7 close behavior for either of their options do not go back to the left or parent that I can tell. 

Maybe moving the 'back to parent' (or to the left) closing behavior code off 'switch to tabs immediately' preference to the 'new default'?  

The problem is some people are used to the old behavior, some are used to switch to tabs immediately behavior and now we have the new behavior on top of that.

Comment 13

[[not reading bugmail]]

If there was a new default say always move left, that would fix all circumstances and I think that's the minimum change that would make this better.  

For example: I think what I read from that statement, is closing tab 4 and going back to say tab 2 is unexpected, but going from tab 4, to tab 3, to tab 2, back toward its parent (or always close and move left) always makes sense.

Jumping directly to the parent doesn't make sense.

Comment 14

[Mike Connor [:mconnor]]

Current behaviour is unchanged since Firefox 2.  The only difference is that we may open tabs not at the end.  The key assumption that this bug makes, IMO, is that related tabs will continue to be related.  That's not a good assumption once you're moving around to different tabs (i.e. if I open a bunch of links from reddit, then switch to gmail in that tab before I go read stuff, that tab really really shouldn't be considered the parent).  If you're operating in a straight queuing fashion (open a few links as you read, close current tab) you'll already get related tabs, in order of opening.  Once you're switching around, that relatively tenuous relation gets fuzzier or just plain wrong, and we shouldn't depend on it.

I do think it's worth experimenting in extension-land around smarter tab closing, but still-related is a hard thing to track.  I've poked at this a few times without finding something that was reliable enough to overcome the unpredictability penalty.

Comment 15

[u88484]

Mike, I understand what you are saying and I hate commenting in bugs after they have been closed (espeically verified WONTFIXed bugs) but I just have to say this.

So instead of doing it right some or most of the time we are going to always do it wrong?  That doesn't make sense.

Lets look at bug #515635.  It is a newley filed bug and none of the devs have commented in in yet but it makes sense.  I know I am assuming and forcasting in the future but if it is fixed, closing that tab will focus tabs on the right and not the related tab on the left. (e.g. reading a news story, searching for a word you don't understand, close tab and focus on tab to the right when focus should have switched to the tab on the left with the news story you are now going to continue to read because you now understand the word).

So again, getting the closing order right sometimes is better than not getting it right at all.

Comment 16

[[not reading bugmail]]

I think I see what Mike is saying how crazy it would be if we tried to factor in special parent behavior ie, related to related.  Maybe this bug should be split.  Discuss enforcing 'always left' or 'always right' or add parenting.

If we drop the need to go to the parent then to that parent's parent arguments, then this gets simpler.  

I think i'm seeing some newly created odd close behavior when I'm trying all the code paths we've created factored in the same session
otherwise the behavior hasn't really changed so much. 

So, maybe we should just have someone cleanup or double check the current code paths of the current tab closing behavior and we should answer the following:

Do 'all' code paths close 'always right'?

Do we 'let switch to immediate' keep its 'always left', or change it to match  'always right'?  Why is this a special case?

Do we 'enforce' FF2 behavior 'always right', or can we change it to 'always left'?  and forgo special related parent closing (which is fine by me).

Comment 17

[Andrew Ramage]

I think adding a data member with related functions may be the cure.

eg - in the definition of the class, have a member relatedd-to-parent   of type BOOL  with qa query function and a function to set it when the child window changes.

Comment 18

[[not reading bugmail]]

(In reply to comment #16)
> I think I see what Mike is saying how crazy it would be if we tried to factor
> in special parent behavior ie, related to related.  Maybe this bug should be
> split.  Discuss enforcing 'always left' or 'always right' or add parenting.
> 
> If we drop the need to go to the parent then to that parent's parent arguments,
> then this gets simpler.  
> 
Filed bug 515717 to discuss non-parenting consistency.


(In reply to comment #14)
> Current behaviour is unchanged since Firefox 2.  The only difference is that we
> may open tabs not at the end.  The key assumption that this bug makes, IMO, is
> that related tabs will continue to be related.  That's not a good assumption
> once you're moving around to different tabs (i.e. if I open a bunch of links
> from reddit, then switch to gmail in that tab before I go read stuff, that tab
> really really shouldn't be considered the parent).  If you're operating in a
> straight queuing fashion (open a few links as you read, close current tab)
> you'll already get related tabs, in order of opening.  Once you're switching
> around, that relatively tenuous relation gets fuzzier or just plain wrong, and
> we shouldn't depend on it.

The user would get lost if I think I understand what you mean.
 
> I do think it's worth experimenting in extension-land around smarter tab
> closing, but still-related is a hard thing to track.  I've poked at this a few
> times without finding something that was reliable enough to overcome the
> unpredictability penalty.

I was thinking about this today, if someone where to take a stab at adding relative parent-child relationships to track relativity, I remember programming linked-lists using pointers with a head and tail to create a memory based dependency tree which could be based off something like the tabIndex(x) id.  

Very similar in theory as the bugzilla dependency (see bug listing treeviews for more) idea.

Comment 19

[Mike Connor [:mconnor]]

(In reply to comment #15)

> So instead of doing it right some or most of the time we are going to always do
> it wrong?  That doesn't make sense.

I explained at least one case where this is exactly right, and closing to the parent would get annoying.  If I queue up a bunch of news stories, and switch to the first one, read it, and close, parent/left are going to be the wrong case.  This is the case that dictates "background by default" for open link in tab, and it's the primary use-case we've designed for, so we can't break this, IMO.

More explicitly:

1 2 3
Open three links from 2
1 2 A B C 3
select A and close.  B is right, 2 is not.  2 might be right after I close B and C, but only if it's still really the parent.  If I've navigated to something unrelated in the meantime, selecting it is almost random.

Getting it right for different cases and wrong for the cases we get it right for now isn't a net win.

> Lets look at bug #515635.  It is a newley filed bug and none of the devs have
> commented in in yet but it makes sense.  I know I am assuming and forcasting in
> the future but if it is fixed, closing that tab will focus tabs on the right
> and not the related tab on the left. (e.g. reading a news story, searching for
> a word you don't understand, close tab and focus on tab to the right when focus
> should have switched to the tab on the left with the news story you are now
> going to continue to read because you now understand the word).

You're assuming a narrow case, where the google search is interrupt-based (you stop what you're doing, search for the term, find out what you're looking for, then resume what you're doing).  If the assumption is that, we should open that tab selected (maybe we should do that, actually, I don't remember why it's a background tab), in which case the longstanding interrupt-driven special case (open in foreground, close without switching away to another tab) comes into play and you get the behaviour you care about.