515717 - Enforce default closing tabs to the left or to the right in FireFox

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[[not reading bugmail]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090910 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090910 Minefield/3.7a1pre

Bug 514796 discusses adding relative tab parenting closing behavior to Firefox and its complications with user expectations.  This is just to discuss enforcing closing tabs 'always right' or switching it to 'always left' regardless of preferences or features. 

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 tab immediate' keep its 'always left', or change it to match 'always right'?  Why is this a special case?

Do we enforce 'always right' behavior, or can we change it to 'always left'?

Reproducible: Sometimes

Actual Results:  
Turning on and off features doesn't have consistent closing behavior.
Ie Relative Tabs, Switch to Immediate tabs, Target Links and New Windows, and Default behavior.

Expected Results:  
Behavior is consistent.

Comment 1

[Tyler Downer [He/Him]]

Same in a new unmodified profile?

Comment 2

[[not reading bugmail]]

All code paths don't have consistent behavior regardless of profile new or old.  Its more that I was trying to replicate the worse possible case by testing everything together and that the user should have consistency anyway.

Comment 3

[Tyler Downer [He/Him]]

I am trying to make sure extensions (such as tab mix plus) are not messing with you.

Comment 4

[[not reading bugmail]]

Yeah, no extensions here.  This is current trunk behavior that needs to be adressed.

Comment 5

[[not reading bugmail]]

see for instance bug 344508.

Comment 6

[Mike Connor [:mconnor]]

(In reply to comment #0)
> Do all code paths close 'always right'?

No, see bug 344508 comment 13 for the one exception, controlled by browser.tabs.selectOwnerOnClose

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

It's not really "always left", it's "select the previous tab under this constrained set of circumstances"  If you disable the "open next to opener" pref, this becomes more obvious, or if you middle-click a bookmark, etc.  If we opened the tab just to the right, in the foreground, closing takes you back to the previous tab, as it always has regardless of relative position.

> Do we enforce 'always right' behavior, or can we change it to 'always left'?

Always left would be a significant change, and would break the longstanding core use case of queuing up related tabs in order, since closing left would not select the next tab in order. No really compelling argument has been made for making this switch except in the single child case.

Comment 7

[[not reading bugmail]]

Thanks Mike, its all starting to make sense whether we're straight queuing, adding relative tabs, doing both or doing things randomly.  So maybe its not so weird after-all.  

I guess the desired behavior depends on the person, if your a straight shooter you move one way or the other, or if your a random person you'd get other results.  I guess that's why i was thinking if it were all the same, it would be easier to think about.

Close behavior is all relative! no pun intended.

Comment 8

[[not reading bugmail]]

Here is another weird one bug 422088.