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.

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.)

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

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

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.

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.

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

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

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

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 ...

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

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!

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

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.)

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

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

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

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.

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.

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.

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

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).

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

Sorry for the bugspam.

The Firefox bug is bug 262459.

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.

(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"

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

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 ?

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.