Open Bug 1485683 Opened 7 years ago Updated 6 months ago

browser.tab.insertaftercurrent order

Categories

(Firefox :: Tabbed Browser, defect, P5)

62 Branch
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

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 !

Severity: normal → S3

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

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.

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

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.

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

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