1938769 - Support browser.tabs.insertRelatedAfterCurrent = false when browser.tabs.insertAfterCurrent = true to open tabs strictly next to current

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, enhancement)

Description

[Sergey Rozhenko]

Steps to reproduce:

Set browser.tabs.insertAfterCurrent = true to always open tabs near current one
Set browser.tabs.insertRelatedAfterCurrent = false

Actual results:

browser.tabs.insertRelatedAfterCurrent has no effect

Expected results:

browser.tabs.insertRelatedAfterCurrent = false should disable the "related tabs" logic. This way last link opened by middle clicking would always be right next to the current tab.

To illustrate:
If I middle-click links 1,2,3 on page 0, I'd like tabs to be 0,3,2,1, instead FireFox places 3-rd link after the 2nd and 2nd after the 1st, resulting in 0,1,2,3.

"Related tabs" logic is wildly inconsistent. It depends on whether I switched to these tabs and interacted with them. Some interactions cause it to forget they were "related".

Comment 1

[Sergey Rozhenko]

The only thing I found to achieve it among addons is https://addons.mozilla.org/en-US/firefox/addon/open-tabs-next-to-current/, which works by moving the tabs after they are opened, but it interferes with "Clipboard to Tabs" addon and occasionally seems to not work.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Sergey Rozhenko]

Upon further consideration, the reordering itself is easy to adapt to. The problem happens when it's unexpected: You open a link or two in new tabs, then proceed to do something in the current tab (say, watch a YouTube video), then open another link and it opens after the first one or two links that you've forgotten about by this point.

So, better solution would be to have a configurable timeout for this group-reordering of new tabs. After it elapses, the browser should forget there were new tabs opened from current tab and place new one right next to current tab.

Comment 4

[Rares Doghi, Desktop QA]

Opening this enhancement. Its a very specific issue but having the ability to customize something like this could be a good thing, as long as its not overcomplicating opening new tabs.

Comment 5

[Ruhollah Majdoddin]

I would like to work on this bug; a patch is ready and I will submit it via
Phabricator.

The underlying semantics, stated once: browser.tabs.insertRelatedAfterCurrent
answers one question - do opener-spawned ("related") tabs get placement near
their opener. false demotes a related tab to an ordinary tab; where ordinary
tabs go is browser.tabs.insertAfterCurrent's decision alone. The current code
implements this demotion incompletely: with insertAfterCurrent=true, a
supposedly-ordinary tab is still steered by the related-chain memory
(#lastRelatedTabMap). That is this bug.

Intended behavior of the pref pair (iac = insertAfterCurrent,
irac = insertRelatedAfterCurrent):

                    related tab (has opener)      unrelated tab

iac=false irac=false end of strip end of strip
iac=false irac=true next to opener (chained) end of strip
iac=true irac=false next to opener, no chain next to selected tab
iac=true irac=true next to opener (chained) next to selected tab

Today the iac=true/irac=false cell wrongly chains; the patch gates the
#lastRelatedTabMap lookup on insertRelatedAfterCurrent so that cell behaves
as the table says. This is exactly what masayuki suggested in bug 1485683
comment 3:

Perhaps, if "browser.tabs.insertRelatedAfterCurrent" is false,
|lastRelatedTab| shouldn't be referred since "related tab" feature isn't
enabled only by "browser.tabs.insertAfterCurrent".

and his next sentence is the scope of this patch: behavior with both prefs
true is deliberately unchanged. Whether the true column should chain or
stack newest-first is bug 1485683's open question and is not touched here.
(For completeness: one combination remains inexpressible with the two
prefs - related tabs next to their opener without chaining while unrelated
tabs open at the end. That, too, belongs to bug 1485683.)

One deliberate side effect while the pref is false: every related tab now
keeps its opener as owner (previously only the first of an uninterrupted
run, and only until the next open revoked it), so closing such a tab
returns focus to the opener. The extended test asserts this.

Regarding comment 3 (the configurable timeout): a timer would reintroduce
exactly the hidden state this configuration exists to remove - bug 1485683
comment 10 asked for "no hidden state I need to guess", and comment 4 here
conditions the enhancement on not overcomplicating tab opening. With this
patch, placement under the pref pair is a pure function of the opener,
with no time dependence. A timeout-based variant for the default
configuration could still be filed as a separate enhancement if wanted.

Bug 1485683 comment 7 said nobody would work on this without a patch that
also extends the automated test. Done: browser_new_tab_insert_position.js
now covers, in all eight pref permutations, a second consecutive related
open, owner assertions, an unrelated tab interleaved between related opens
(2056760's scenario 4), and consecutive related opens from a pinned opener.

Validation: I could not yet run the mochitest locally (no build), so the
expectations were verified against a live Nightly 155.0a1 using the
Debugger API to emulate the gate on the unpatched build (a frame-local
write-back at the patched line): all eight permutations pass every
position and owner checkpoint, and a stock-build control run fails exactly
the four checkpoints the patch targets, nothing else. I would appreciate a
try push for the mochitest. This work was done with AI assistance; I have
reviewed and can explain every line.

Bug 2056760 reports the same defect in this pref pair (its scenarios 1-4
match the patched behavior, including scenario 4, which the new interleave
test covers) and can be duped here once this lands.

Comment 6

[Ruhollah Majdoddin]

Attachment: Bug 1938769 - Don't apply related-tab chaining when insertRelatedAfterCurrent is false. r?#tabbrowser-reviewers,dao

With browser.tabs.insertRelatedAfterCurrent=false and
browser.tabs.insertAfterCurrent=true, #insertTabAtIndex still read
#lastRelatedTabMap, so consecutive related tabs chained left to right
behind their opener even though the related-tab feature was disabled.
Gate the lookup on the pref: a demoted related tab is then placed like
any other tab, immediately after its opener (bug 1485683 comment 3).
Behavior with both prefs true is unchanged.

Behavior change while the pref is false: every related tab now keeps
its opener as owner (previously only the first of an uninterrupted
run, until the next open revoked it), so closing it returns focus to
the opener. The map write stays ungated because the map is also read
on tab switch to clear the last related tab's owner.

Extends browser_new_tab_insert_position.js with, per permutation: a
second consecutive related open, owner assertions for both related
tabs, an unrelated tab interleaved before a third related open (the
tab switch resets the chain), and consecutive related opens from a
pinned opener.

Comment 7

[Ruhollah Majdoddin]

The table in comment 5 lost its alignment (Markdown collapsed the
indentation); here it is again:

                      related tab (has opener)   unrelated tab
iac=false irac=false  end of strip               end of strip
iac=false irac=true   next to opener (chained)   end of strip
iac=true  irac=false  next to opener, no chain   next to selected tab
iac=true  irac=true   next to opener (chained)   next to selected tab

(iac = browser.tabs.insertAfterCurrent, irac =
browser.tabs.insertRelatedAfterCurrent. The iac=true/irac=false cell is
this bug: it currently chains; the patch makes it behave as shown.)

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/45e5e078f302
https://hg.mozilla.org/integration/autoland/rev/9536c3f0853c
Don't apply related-tab chaining when insertRelatedAfterCurrent is false. r=dao,tabbrowser-reviewers

Comment 10

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/9536c3f0853c

Comment 11

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Nightly 156.0a1 (2026-08-16). This is awesome !