Bug 1344749 implements browserSettings.newRelatedTabPosition with support for “afterCurrent” and “endOfTabStrip”. The “afterCurrent” value actually means “after the last existing tab related to current”, so having two tabs [a][b] and middle-clicking links to [1], [2] and [3] in this order will produce [a][1][2][3][b]. Tab Mix Plus had an option to reverse the order of related tabs. The same case would produce [a][3][2][1][b]. Along with a possibility to customize tab closing to focus the preceding tab, as suggested in bug 1422509, it leads to the desirable outcome that opening several related tabs and then closing them returns focus to the original tab [a]. (Bug 1226546 should depend on this one.) Proposal: * Add another possible value for newRelatedTabPosition, let’s say, “immediatelyAfterCurrent”. * Add a corresponding preference, let’s say, browser.tabs.insertRelatedImmediatelyAfterCurrent, boolean, default false. * When insertRelatedImmediatelyAfterCurrent is true, open new related tabs at the position immediately following the current tab, regardless of any existing related tabs. (Names subject to discussion.) The corresponding new unrelated tab API does not need to change accordingly.

Discussion - comments 80-86: https://bugzilla.mozilla.org/show_bug.cgi?id=1344749#c80

The decision has been made to not pursue bug 1344749. As a dependency of that bug, this one can no longer be implemented.

Bug 1344749 is now verified fixed. Does that make this one feasible again?

(In reply to Jack from comment #3) > Bug 1344749 is now verified fixed. Does that make this one feasible again? It makes this feasible again. The biggest issue is that the browser does not currently support this behavior, and I'm not aware of any plans to add that support. I will mark this as P5 (patches accepted) and if/when Firefox supports the desired behavior (perhaps via another patch), it would be good to expose it via the WebExtensions API.