Open Bug 1485683 Opened 6 years ago Updated 11 months ago

browser.tab.insertaftercurrent order

Categories

(Firefox :: Tabbed Browser, defect, P5)

Product:
Firefox
Component:
Tabbed Browser
Version:
62 Branch
Type:
defect

Tracking

()

People

(Reporter: larabe, Unassigned)

References

(Blocks 1 open bug)

Details

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
Component: Untriaged → Tabbed Browser
Blocks: 1344749
Priority: -- → P5
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.
Flags: needinfo?(larabe)
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.
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.
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?
Flags: needinfo?(larabe) → needinfo?(masayuki)
Sorry, I'm working on a lot of big changes in my modules so that I don't have much time.
Flags: needinfo?(masayuki)
Could you tag or refer me to someone that could help us with this? Thank you.
Flags: needinfo?(masayuki)
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.
Flags: needinfo?(masayuki)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 1442843

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.

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

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

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.

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

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.

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)

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

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 !

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

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

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.

Severity: normal → S3

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.

Flags: needinfo?(dao+bmo)

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.

Flags: needinfo?(dao+bmo)

(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

You need to log in before you can comment on or make changes to this bug.