1485683 - browser.tab.insertaftercurrent order

Status: NEW

(Firefox :: Tabbed Browser, defect, P5)

Description

[larabe]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180820172315

Steps to reproduce:

With browser.tab.insertaftercurrent by the name and probably by most users would be expected to ALWAYS insert the new tab after current


Actual results:

Tabs will arrange themselves putting the oldest tab the closest to the current and the newest the farthest away and also use some kind of timer to determine this so If you open it in succession it will try to put the newest tab as the farthest from the related tabs that you just opened instead of the closest.

Example C 1 2 3 4 5 instead of being C 5 4 3 2 1

C being current tab and 1 the first open tab (the oldest) from the succession of opened tabs and 5 being the newest tab (the last one opened).

Now the craziest thing will happen when you stay on the same tab and open a few tabs then wait and open a few more for example If you open 3 one after an other but after a bit open 3 more with will look something like this

C 4 5 6 1 2 3

Which is just not right IMO. This is confusing and certainly not expected.


Expected results:

Tabs should open always next to current 

or 

add this as browser.tab.insertaftercurrent > 1 and the actual behavior as browser.tab.insertaftercurrent > 2 if you think how it works now would be preferred by some users

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't understand what is problem here. Could you explain "Steps to reproduce" with listed steps? The new pref was designed for new tabs which are not managed by browser.tabs.insertRelatedAfterCurrent.

Comment 2

[Denis Lisov]

The problem here is that some users expect an option called "insertAfterCurrent" to insert a tab after the current one, not after the current one and possibly some "related" tabs, which are forgotten at some non-obvious points in time.

The insertion order used at the moment feels rather inconsistent to us. For example:

Suppose I'm reading an article with references numbered (1) to (4) and open each of them in the background with a middle click. 

Actions:
- open the article
- middle-click (1)
- middle-click (2)
- middle-click (3)
- middle-click (4)
Tab order: (current) (1) (2) (3) (4)

Actions:
- open the article
- middle-click (1)
- middle-click (2)
- switch to another tab (say, check a new email) and back to the article
- middle-click (3)
- middle-click (4)
Tab order: (current) (3) (4) (1) (2)

Actions:
- open the article
- middle-click (1)
- middle-click (2)
- middle-click (3)
- middle-click (3) again by mistake
- middle-click any one of the (3) tabs to close it (don't really need two of them)
- middle-click (4)
Tab order: (current) (4) (1) (2) (3)

Actions:
- open the article
- middle-click (1)
- switch to (1) tab and back (checking whether that's the data I want)
- middle-click (2)
- middle-click (3)
- middle-click (4)
Tab order: (current) (2) (3) (4) (1)

All these sequences of actions are almost equivalent from the user's point of view (I'm reading the article with minor distractions), but result in different tab order as a result, which feels inconsistent. Basically, with the "insert after current" policy there's no obvious way to know whether the user is still in the same mental context ("I've just opened (1) to (3) and expect (4) to open after them") or in a new context ("I just expect this new link (4) to open right after the current tab, as usual").

An option that is a bit less obvious, but more consistent internally, is to always open the new tab right after the current one, not taking any "related" tabs into account. In this case, the tab order after the operations above will be
(current) (4) (3) (2) (1)
in any of the scenarios. This option is more predictable for a user as it does not require any context to know where the next tab will open. Thus there is a population of users, previously using addons, who would be willing to have this predictability even at the cost of getting the tabs in the reverse order.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you for the explanation.

The motivation to implement "browser.tabs.insertAfterCurrent" is, not open new tab from a specific tab, I wanted it for opening from another application or opening bookmark, etc to immediately after current tab for avoiding making hard to go back to previous active tab.

(In reply to Denis Lisov from comment #2)
> An option that is a bit less obvious, but more consistent internally, is to
> always open the new tab right after the current one, not taking any
> "related" tabs into account. In this case, the tab order after the
> operations above will be
> (current) (4) (3) (2) (1)
> in any of the scenarios. This option is more predictable for a user as it
> does not require any context to know where the next tab will open.

Sure. Perhaps, if "browser.tabs.insertRelatedAfterCurrent" is false, |lastRelatedTab| shouldn't be referred since "related tab" feature isn't enabled only by "browser.tabs.insertAfterCurrent". But if both of them set to true, I don't think that current behavior is so bad except that current context is unclear.

Comment 4

[larabe]

Thank you Denis for explaining it.

Currently having "browser.tabs.insertRelatedAfterCurrent" true or false does not change the behavior of "browser.tabs.insertAfterCurrent". What you suggested is a nice idea. Do you think you could implement it?

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry, I'm working on a lot of big changes in my modules so that I don't have much time.

Comment 6

[larabe]

Could you tag or refer me to someone that could help us with this? Thank you.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If I knew such people, I didn't write the original patch by myself. (And this is already marked as P5 and I agree with the prioritization.) Perhaps, unless you'd create a patch with modifying the automated test, nobody would work on this.

Comment 8

[vagmer]

Can this please be fixed? I think it's crazy it's still broken, as I have been suffering from this behavior continuously ever since we lost Tab Mix Plus. :(
Obviously, I'm not the only one... Currently even with this pref enabled, to this day, the tab opening order/placement in Firefox feels almost virtually "random" in practice (as has been described in this thread), and this impairs workflow. I couldn't even find any extension to properly fix this, though I really think this kind of basic customization should be native in the browser and is part of what sets Firefox apart from Chrome. If it's tucked away buried in a pref instead of appearing as an option anywhere... then so be it - personally I don't care much as I am unaffected, though the average user will be...

I also think "the reverse" - what tab gains focus when the current tab is closed - should be natively customizable in a clean manner as well. I currently have to use this extension for this: https://addons.mozilla.org/en-US/firefox/addon/focus-on-left-tab-aft-closing/ , and unfortunately it's not perfect (stops working once in a while until you disable-enable it and then wait/mess around a short while). I don't know if this is due to WebExtension limitations or if it could be done better, but it would be nice to be able to control this basic browser behavior with a pref.

Comment 9

[avada]

(In reply to Denis Lisov from comment #2)

Actions:

• open the article
• middle-click (1)
• middle-click (2)
• middle-click (3)
• middle-click (4)
  Tab order: (current) (1) (2) (3) (4)

Actions:

• open the article
• middle-click (1)
• middle-click (2)
• switch to another tab (say, check a new email) and back to the article
• middle-click (3)
• middle-click (4)
  Tab order: (current) (3) (4) (1) (2)

Actions:

• open the article
• middle-click (1)
• middle-click (2)
• middle-click (3)
• middle-click (3) again by mistake
• middle-click any one of the (3) tabs to close it (don't really need two of
  them)
• middle-click (4)
  Tab order: (current) (4) (1) (2) (3)

Actions:

• open the article
• middle-click (1)
• switch to (1) tab and back (checking whether that's the data I want)
• middle-click (2)
• middle-click (3)
• middle-click (4)
  Tab order: (current) (2) (3) (4) (1)

I think all of these are reasonable. Except the one with closing the tab. Because if you not switch away from a tab to close it it should make no difference. (Though it works this way with the old xul FF + tab mix plus combination as well)

Now I don't see the issue from the OP:
"stay on the same tab and open a few tabs then wait and open a few more for example If you open 3 one after an other but after a bit open 3 more with will look something like this

C 4 5 6 1 2 3"

Does this actually happen? Because it's definitely a bad idea to have some hidden timer for this in my opinion.

Comment 10

[Denis Lisov]

(In reply to avada from comment #9)

(In reply to Denis Lisov from comment #2)

[a few sets of actions -> tab order groups]

I think all of these are reasonable. Except the one with closing the tab. Because if you not switch away from a tab to close it it should make no difference. (Though it works this way with the old xul FF + tab mix plus combination as well)

I don't agree with you.

That being said, I do understand what Firefox is trying to do with these sequences. The common logic behind them seems to be roughly summarized by the following two rules:

• if the user opens several tabs in a row without switching context, open them after the current left-to-right;
• when the user changes context, forget about the recently opened tabs and start from the current tab again.

The problem is that the difference between "the user changes context" and "the user keeps context" here is a heuristic that works good for some people and not so good for others. The two kinds of errors are both possible here: false negatives can happen when a person loses context due to a distraction Firefox does not know about (for example, they can do something in a different Firefox window, or in a non-Firefox one, be distracted by a trailer on their TV, receive a phone call, etc.) while false positives can happen when a user does something Firefox considers a distraction but still keeps the mental context (for example, they can switch to a different tab for a quick check that does not require much thinking, or they can come back to what they were reading and specifically recall what they'd seen and opened before switching away).

In both error cases the Firefox behavior is surprising to the user because Firefox tries (and fails) to guess whether the user feels like coming back to what they were doing or like just visiting the same page again, probably not from the very beginning, but not trying to continue the previous operations. This mismatch sometimes is really confusing, and that's why I'm asking for Firefox to (at least have an option to) use some behavior that's both local (not in the very end of the tab bar) and completely predictable (no hidden state I need to guess like "wait, did I switch tabs or not before the last break").

So basically the current behavior looks to me like a tightrope. There's a nice straight path which has tabs open after the current, left-to-right... but if you want it to work consistently, you must not switch tabs as long as you're not finished. Either that, or you need to come back, find the latest opened tab and move the "parent" tab after it manually to continue the sequence. If there's a simple but urgent question in a chat in another tab... well, sorry, you're out of luck.

By the way, an especially annoying moment is that this sequence is forced on me. I cannot just drag one tab if I want to reorder it to a different place because that automatically switches me to that tab and breaks the sequence.

Now I don't see the issue from the OP:
"stay on the same tab and open a few tabs then wait and open a few more for example If you open 3 one after an other but after a bit open 3 more with will look something like this

C 4 5 6 1 2 3"

Does this actually happen? Because it's definitely a bad idea to have some hidden timer for this in my opinion.

This one I could not reproduce. I'd guess that "after a bit" here is a representation of "after I did something else for a bit" and shows that, at least for some users, the "context switch" heuristic is non-obvious and they don't expect switching to something else and back to affect the tab order.

Comment 11

[vagmer]

Yeah, just maybe the browser behaving inconsistently because it's trying to read the user's mind is a bad idea to begin with... Either way, it still being forced upon users that have explicitly enabled a preference called "browser.tab.insertaftercurrent" is of course a bug.

If one wanted to make it possible to have this inconsistent placement-behavior together with the not opening tabs at the end of the tab bar-behavior, one would want to rename existing "insertaftercurrent" pref to be accurate to its existing function and add a new, dedicated preference to govern the inconsistent placement-behavior, perhaps called something like "browser.tab.noguessinginsertionorder" or "browser.tab.consistentinsertionorder" - or more clinically "browser.tab.insertionorderheuristics", though harder to understand. Then the user can choose any combination. Personally I only care for this bug to be fixed.

Comment 12

[pica]

If I am on a web page and I middle-click to open a link in a new tab, the first tab opens after the current tab I am in.

However, if I then middle-click on another link, the tab does not open after the current tab, but instead it opens after the previously opened tab. That should not happen. The tab should always open after the current tab, and the current tab always refers to the actual tab I am viewing.

I have browser.tabs.insertAfterCurrent and browser.tabs.insertRelatedAfterCurrent both set to true, and changing either or both settings has no effect on this behavior.

Also, this is only happening on Firefox for Linux, not Windows.

Name Firefox
Version 89.0.2
Build ID 20210622155641
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0
OS Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-1 (2021-06-24)
Application Binary /opt/firefox/firefox-bin

Comment 13

[andrewinput]

browser.tabs.insertAfterCurrent no longer works on Linux, Windows and iOS. Also browser.tabs.insertRelatedAfterCurrent and Addons created to fix this issue which firefox has had in the past (lack of a simply predictable tab opening policy) are no longer working.

Having tabs open in an awkward order (sometimes they open off screen) - with no way for user select the simpler to understand (and implement) behavior, seems quite tragic. This issue was serious enough to generate enough complaints for Addons and config options to made to fix it. I really hope it gets fixed.

Comment 14

[Kaushal]

Hello, I ended up on this issue after going through a rabbit hole of links. Can this issue please please be fixed?

I do have set browser.tabs.insertAfterCurrent to true. But that seems to make no difference when middle-clicking links on a page. It only affect where a New Tab is created when hitting Ctrl + T or clicking the new tab button.

May be we need a new browser.tabs.insertAfterCurrentOnMiddleClicks option?

Current behavior

Actions:

• open the article
• middle-click (1)
• middle-click (2)
• middle-click (3)
  Tab order: (current) (1) (2) (3)

Expected behavior

Actions:

• open the article
• middle-click (1)
• middle-click (2)
• middle-click (3)
  Tab order: (current) (3) (2) (1)

Comment 15

[avada]

(In reply to Kaushal from comment #14)

I do have set browser.tabs.insertAfterCurrent to true. But that seems to make no difference when middle-clicking links on a page. It only affect where a New Tab is created when hitting Ctrl + T or clicking the new tab button.

Isn't browser.tabs.insertRelatedAfterCurrent is for middle clicked links and such? But that's true by default.

Comment 16

[andrewinput]

For me it turned out that a browser extension was causing the behavior. It was 'Tree Style Tab' in particular which has settings affecting tab order. It was unexpected because I use it only occasionally to review the list of open tabs. After re-configuring the extension Firefox tab insertion behaved perfectly again respecting about:config.
I do apologise for not correcting my bug report till now - I lost the thread. Check those extensions !

Comment 17

[Kaushal]

(In reply to avada from comment #15)

Isn't browser.tabs.insertRelatedAfterCurrent is for middle clicked links and such? But that's true by default.

That's right, browser.tabs.insertRelatedAfterCurrent is true by default and I had verified that's the case, and that doesn't seem to work. Are you able to reproduce this issue?

Comment 18

[Kaushal]

(In reply to andrewinput from comment #16)

For me it turned out that a browser extension was causing the behavior. It was 'Tree Style Tab' in particular which has settings affecting tab order. It was unexpected because I use it only occasionally to review the list of open tabs. After re-configuring the extension Firefox tab insertion behaved perfectly again respecting about:config.
I do apologise for not correcting my bug report till now - I lost the thread. Check those extensions !

I did have the Tree Style Tab add-on added earlier. But I've already uninstalled that and restarted Firefox a few times since. I am also able to reproduce this issue in Troubleshooting Mode where all extensions are disabled.

Just to clarify, when you consecutively use middle clicks to open links in new tabs, do those tabs open immediately to the right of the current tab? The only way I was able to achieve that is by installing the Open Tabs Next to Current add-on. I've elaborated on the issue I'm seeing with diagrams in a blog post yesterday.

Comment 19

[andrewinput]

Hello Kaushai - thankyou for clarifying. I think you are correct. I disabled all extensions and restarted with only the two config:about options set to true ( browser.tabs.insertAfterCurrent and browser.tabs.insertRelatedAfterCurrent) and after restart, middle click "open link in new tab" did not respect them. So it does still seem to require an extension to fix it.

Thankyou for putting up the blog post, I hope others can find it when needed. It is quite problematic that the most visible and official answer on this issue, is that it has been solved in the config, when it has not. Tree Style Tabs has a setting which fixes it, but if set wrong it stops other addons from fixing it. So that can add to the confusion. But the confusion is underpinned by an about:config setting not working as reported.

Comment 20

[BugBot [:suhaib / :marco]]

The severity field for this bug is relatively low, S3. However, the bug has 72 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 21

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 22

[Owl]

(In reply to andrewinput from comment #16)

For me it turned out that a browser extension was causing the behavior. It was 'Tree Style Tab' in particular which has settings affecting tab order. It was unexpected because I use it only occasionally to review the list of open tabs. After re-configuring the extension Firefox tab insertion behaved perfectly again respecting about:config.
I do apologise for not correcting my bug report till now - I lost the thread. Check those extensions !

Thank you for saving me from going insane! This extension caused the problem for me as well

Comment 23

[Hans S.]

Same issue here. browser.tabs.insertAfterCurrent does not work properly. Even 6 years later. Just wow.

If you have tabs next to the right of the same base URL, like www.cnn.com and you open new tabs, it wont open them to the current one, but to the far right of the same url. This needs to be changed!

Comment 24

[pica]

(In reply to Hans S. from comment #23)

Same issue here. browser.tabs.insertAfterCurrent does not work properly. Even 6 years later. Just wow.

If you have tabs next to the right of the same base URL, like www.cnn.com and you open new tabs, it wont open them to the current one, but to the far right of the same url. This needs to be changed!

Did you try setting browser.tabs.insertRelatedAfterCurrent to true ?

Comment 25

[Hans S.]

Yes I did. It was default on true. Has no difference if set to true or false. I found a workaround which works, using this addon:

https://addons.mozilla.org/en-US/firefox/addon/open-tabs-next-to-current/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search

But it is ridiculous that you need an addon for this, which maybe could include malicious code.

Comment 26

[Albert Scheiner [:alberts]]

@Hans - I am a user of "Always right" for many years. Seeing your comment I just tested this, switched the addon off, and made sure that tabs then opened at the end of all other tabs again. Next, I set browser.tabs.insertRelatedAfterCurrent manually to true and it works for me like a charm.

Tested with Firefox on macOS:

• 131.0
• 132.0b4

Tested opening by:

• clicking the + button in the toolbar bar
• pressing Cmd + T
• holding Cmd + clicking a link
• right click -> Open Link in New Tab

Have you tried Help -> Troubleshooting Mode, to test without any addons being loaded?

Comment 27

[Denis Lisov]

As far as I see, everything still works in the same way it did in comment 2. In brief, if I open multiple tabs with middle-click or "open in new tab" (without switching to them),

• the first new tab is inserted after current,
• the second new tab is inserted not after current, but after the first one,
• the third new tab is inserted after the second one
  and so on until something causes Firefox to forget these "recently opened tabs", such as switching to a different tab or closing any of them.

Comment 28

[Hans S.]

I expect every tab to be inserted right next to the current tab I am on when I enable "insertAfterCurrent". But it doesnt behave like this:

Tab1
TabCurrent (not cnn.com)
Tab3
Tab4

Opening cnn.com:

Tab1
TabCurrent
Cnn.com
Tab4
Tab5

Opening another cnn.com:

Tab1
TabCurrent
Cnn.com
2nd cnn.com
Tab5
Tab6

This is not I expect insertAfterCurrent to work. It is ignoring insertAfterCurrent and just inserts the same domain on the far right side of same domains. This is really bad and kinda disables the function of insertAfterCurrent again.

No matter what, insertAfterCurrent=1 should always insert right next to current tab.

Comment 29

[avada]

(In reply to Hans S. from comment #28)

I expect every tab to be inserted right next to the current tab I am on when I enable "insertAfterCurrent". But it doesnt behave like this:

No matter what, insertAfterCurrent=1 should always insert right next to current tab.

If you're preferences differ from the default way things work then you customize. No need to whine about what you prefer is the "right way" it should work. It always placed tabs (in order) from left to right as long as you didn't switch to them, it's the most logical thing to do.

Comment 30

[Hans S.]

You know what these words mean, right? It is not so hard to understand 3 little words: Insert after current.

Comment 31

[avada]

(In reply to Hans S. from comment #30)

You know what these words mean, right? It is not so hard to understand 3 little words: Insert after current.

And they're inserted in the order they were opened, as it is logical.

Comment 32

[Hans S.]

I want to clarify why the "Insert After Current" option is so important. The purpose of this feature is to ensure that when you open a new tab, it appears right next to the current one. This makes it easy to see and interact with, especially if you already have many tabs open.

When new tabs are placed at the far right—particularly if you have 100 tabs open—it’s almost impossible to locate and use them right away. This defeats the purpose of "Insert After Current," as it's intended to improve tab visibility and usability.

However, the current implementation doesn’t always follow this behavior, especially with multiple tabs from the same domain. In such cases, new tabs often end up on the far right, ignoring the "Insert After Current" setting. This setting should consistently place new tabs next to the current one, with no exceptions.

For better usability, it would be great to have this adjusted so "Insert After Current" always works as expected. Thank you for considering this improvement.

Comment 33

[Lazy Monkey]

(In reply to avada from comment #31)

And they're inserted in the order they were opened, as it is logical.

You're wrong.

In english "Insert after current" has a precise meaning, i.e. you add new tabs beside the current one.
Unless you change tabs the current tab is always the same tab, even after you opened two, three or more tabs.

Otherwise the option's name should be "insert after latest tab opened".

Comment 34

[Worcester12345]

This is an opinion thing, not so "precise".

I would think that each new one BECOMES the "current tab".