161836 - New tabs should open to the right of current tab

Status: RESOLVED FIXED

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[Brad Nixon]

This is a feature request to change the way new tabs are opened in Mozilla.
Currently, when a new tab is opened, it appears at the end of the tab list. This
bug requests that the new tab be placed immediately to the right of the parent
tab, as is the behavior in Chimera and Netcaptor.

This is a reasonable compromise to the requests to change the way tabs are
closed, ie bug 144207, bug 105722, and bug 131037.

This behavior was mentioned in 105722 comment 78 by David Hyatt, and Peter
Trudelle invited a bug for a Mozilla implementation of this behavior. So here it is.

Comment 1

[Sander]

I don't think this would be a good thing. Consider the following (in my
experience very common) scenario:

You're looking at a list of links, and open quite a few of them in tabs. At the
end of this process the link you followed first is now located way to the right,
while the last link you followed is probably still loading just to the right of
the current tab, and will be showing upon closing the current tab. But chances
are you will first want to read the tab you opened first (for example, when
dealing with the chronological order of archived mailinglists, or search results
where you will first want to look at the highest ranked results as they have the
most chance of being what you're looking for), so that requires manually
focussing that first opened tab, and then the current closing behaviour would
have you once more focussing tabs constantly.

Opening a new tab immediately to the right of the current tab is in my opinion
only beneficial if you only follow one link per page - yet the strength of
tabbed browsing is that you regularly follow dozens of links.


However, slightly changing the proposal, I think this could lead to even more
efficient tabbed browsing (requiring less manual focussing) than is already the
case if: 
the first tab opened from a page opens immediately to the right of the current
tab, and the next tab opens immediately to the right of that tab. So we would
retain the way multiple tabs opening currently works (left to right), but then
inserted immediately next to the current tab.

Schematically, what happens if you have three tabs (A, B, and C) and open two
new tabs from each of those pages:
right now: A-B-C -> A-B-C-A1-A2-B1-B2-C1-C2
proposed: A-B-C -> A-A2-A1-B-B2-B1-C-C2-C1
my proposal: A-B-C -> A-A1-A2-B-B1-B2-C-C1-C2

The biggest problem I see with both proposals is that when you're dealing with a
large number of tabs (10+) it might become confusing to some users to identify
where new tabs are opened. (Which was I believe the argument against inserting
bookmark groups immediately to the right of the current tab.)

Comment 2

[R.K.Aa.]

*** Bug 165157 has been marked as a duplicate of this bug. ***

Comment 3

[Malcolm Rowe]

*** Bug 143877 has been marked as a duplicate of this bug. ***

Comment 4

[Jason Bassford]

I like the solution in comment 1 better than what was originally proposed for
this bug.  However, I still have problems with the overall concept of this.

Say, I'm browsing a news site - I do this daily - and I'm opening links to news
that I want to read, each in its own tab.

I keep the main news site open, as a reference point, and when I go to the 2nd
tab and read that article, I find more stories that I'm interested in so I open
some more tabs.  In both the original scenario for this bug and in the revised
one from comment 1, these new tabs will open immediately to the right of the 2nd
tab.

When I close the 2nd tab (I'm finished with that article), the next tab I'm
presented with is the first link I clicked on from the now closed 2nd tab.  But
that's not what I want to see next.  What I want to see next is the 2nd link I
clicked on from the main reference page (tab 1).

Doing it this way means that I lose my first clicked / first read order that I
want to keep things in.  It's akin to the problem described in comment 1, but at
a more global level.

If I want to group tabs in terms of content, then what I would do is open
completely new content sites in new *windows* then browse each of those via new
*tabs* in their respective window.

I think that the current behaviour works just fine.

Comment 5

[Sander]

Originally I would have agreed with comment 4, but when I thought about this
when writing comment 1, I realized that my clickthrough rate is usually pretty
low; meaning, I hardly ever follow links from a followed link when doing normal
browsing. (Only in bugzilla does this happen regularly, and for most of those
cases I set up yet another tabgroup.)
Taking the example of the news site, when I _do_ follow a link from one of the
news articles, it's usually only to have a quick peek around - something I'd
rather do immediately after reading the article, instead of waiting until I'd
read half a dozen articles and forgotten all about the first one again.

I do agree however that the current behaviour works just fine; and certainly
good enough, so I'll be okay with most any way this will eventually be resolved.

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 170386 has been marked as a duplicate of this bug. ***

Comment 7

[Aaron Green, MD]

I still like Comment 1's solution most; but it looks like what we ultimately 
need to move towards is some kind of grouping of tabs.

Consider, for ex:

1) Given page BASEPAGE, when you open a link in a new tab from that page, the 
tab for BASEPAGE changes color; the new tab (as well as other tabs created from 
links on BASEPAGE) have the same color. If on one of those "child" pages you 
open more links in new tabs, the "child" page and *its* children could be a 
lighter shade of the same color. This would make a cool "rainbow" effect [with 
some "wow" factors for reviewers ;)] and visually group the pages. 
  EVEN WHEN YOU CLOSE a given tab, the pages opened from that tab would still 
be visually grouped. I think that solves some of the disagreement about what 
tabs should be in front after you close a given tab. For ex., if I'm 
reading "child" tab 1 and close the child tab, I *want* to read *its* children 
(unlike a previous poster). Both I and the other poster will at any rate be 
able to see the groupings if the colors/shades idea were implemented.

2) Some kind of "second row" of tabs. That row would generally represent all 
tabs that are children of some BASE page. The question is how to determine when 
that row is refreshed--for ex, if you switch to tab "B1" and the "second row" 
of tabs shows all the tabs that were spawned from tab "B1", that's great; 
however when you close "B1" you might still want to see its spawned pages but 
now "B1" is closed! 
   Perhaps in this case (multiple tabs spawned from "B1" but "B1" is now 
closed), when you switch to one of "B1"s spawned tabs, the referring tab ("B1") 
could be presented as a "ghost" on the main tab line (or all the way on the 
left of the "second row"), and the "second row" of tabs could show all tabs 
that were spawned from "B1" (the "sibling tabs," if you will). 
   Instead of all these "guesses" about what the user wants to see on 
the "second row," consider this: when viewing ANY TAB, the user can select to 
have the "second row" show ALL TABS THAT WERE SPAWNED FROM THE SAME SITE AS THE 
CURRENT TAB. That would be a very quick, flexible, way to get exactly the group 
that you want to see, regardless of where in the "tree" of links you are 
viewing! 
   The natural complement to this, of course, would be a function to show all 
tabs that were opened from the CURRENT tab in the "second row" of tabs...
   How one would navigate to the "second row" of tabs is another story :P

Comment 8

[Aaron Green, MD]

Ping!

Hope to get at least an intermediate addressing of this issue... :)

Comment 9

[Thibault G.]

You should have a look at :

http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en

This is an extension to the tab management of mozilla, 
and allows (among other things) to open new tab at the right
of the current tab.

In fact, I don't know if it is possible, but this extension 
should probably be merged with mozilla ...

Comment 10

[Michael Lefevre]

*** Bug 171238 has been marked as a duplicate of this bug. ***

Comment 11

[Aaron Green, MD]

http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en is just amazing! From
multicolored tabs to ability to Undo Close Tab to saving groups of tabs...

Really should be integrated into mozilla!

Comment 12

[Jason Bassford]

Undo close tab is bug 152391 and tab groups have been available for many months
now. 

Comment 13

[Jason Bassford]

I would also propose (as a possible extension to this existing bug) that the
context menus list, by default, only single-tab actions, and that the modifier
change any equivalent single-tab action to a multiple tab action - and not just
"Close Other Tabs".

I.e.

Close Tab -> Close Other Tabs
Bookmark This Tab -> Bookmark This Group of Tabs
Reload Tab -> Reload All Tabs

Holding down the modifier key would dynamically change the text listed in the
menus.  (And there should be some indication that this is available.)

Comment 14

[Jason Bassford]

Sorry!  That comment should have been in bug 191492.  My apologies. 

Comment 15

[Stefan Borggraefe]

*** Bug 240386 has been marked as a duplicate of this bug. ***

Comment 16

[Samir L. Boulema]

Would like to see this too. or atleast and extension thats a bit less bloated
than TBE that will bring this functionality.

Comment 17

[Klaus Kusche]

One more vote for this.

I just switched over from Konqueror, and in Konqueror, it is a Preferences
Option if a new tab should be opened at the end or next to its parent tab.
Opening it next to its parent keeps related tabs together.

Comment 18

[Gummi]

I agree with this, curren behaviour is annoying because I need to get to the
last tab (not fast with ctrl + page down), then I need to remember where was the
last page to go back to it.
The original solution is good enough. The first comment improves on it by
memorizing last tab opened by current tab (epiphany does this, and forgets it
when one switches tabs - this is good too).
The ultimate solution would be to use a hierarchy for tabs. It could still look
the usual way, but use ctrl shift page-up, ctrl shift page-down, for switching
between tabs of the same level, and ctrl page-up, ctrl page-down regardess of
the level. Then, a sidebar could allow for displaying the hierarchy.

I'd like to see the code from tbe merged anyway, as it already exists and the
full tbe has been said to be bloated.

Comment 19

[John Mellor (Jomel)]

I have implemented this behaviour (as ammended in comment 1) as a Firefox extension, available from http://jomel.me.uk/software/firefox/tabsopenrelative/
This could be useful for UI testing or for users wanting an immediate solution.

It would be fairly simple to incorporate this change, it could take as little as a 3 lines.

Comment 20

[Adam Guthrie]

*** Bug 325231 has been marked as a duplicate of this bug. ***

Comment 21

[Simon Bünzli]

Attachment: allow to customize this behavior

This patch adds a new pref (browser.tabs.tabOpenLogic) which allows to control where new tabs are added. It supports both schemes

[A 1 2 3 B C] and [A 3 2 1 B C]

(where the numbered tabs are added in the background from tab A) and allows to specify whether blank tabs (which nicely includes tabs opened from external applications) should be handled specially or not.

Should this be the way to go, we'll have to think the default behavior over (I propose to open non-blank tabs in the IMHO expected order [A 1 2 3 B C], but I don't really care as long as it's customizable).

Comment 22

[Mike Connor [:mconnor]]

this is really a seamonkey bug, please file a firefox bug and attach the patch there for appropriate reviews.

Comment 23

[Simon Bünzli]

Sorry for the bugspam.

Comment 24

[Jesse Ruderman]

The Firefox bug is bug 262459.

Comment 26

[romb]

John Mellor (Jomel) (comment#19) implemented nice add-on as an immediate solution.
You may use it as a good start.
E.g. Maxthon browser has this option (where to open a new tab) in configuration.
Anyway current behavior is annoying.

Comment 27

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

(In reply to comment #24)
> The Firefox bug is bug 262459.

It's not, really. That's about adding an option, which is WONTFIX. Firefox could probably use its own bug about changing the default behaviour of "where new tabs should open"

Comment 28

[ronin.achilles]

Firefox Bug to change default Tab Opening position/behavior: Bug #465673

Comment 29

[Misak Khachatryan]

Seamonkey also implements Firefox behavior now. What should be done with this bug ? The current behavior is IMHO reasonable compromise and Tabs Open Relative implements exact behavior from this bug description. WONFIX ?

Comment 30

[Philip Chee]

Marking this as FIXED by patch in Bug 558614. Any fine tuning or adjustments in the algorithm should be filed as separate followup enhancement bugs.