New tabs open to the right of all existing tabs instead of opening next to the current tab

[Jani Uusitalo]

Binary package hint: firefox

As the summary says: when a user opens a new, empty tab, it opens next to the rightmost of tabs currently open in the browser. This is inconsistent with the way links in new tabs are opened, which is to have them next to the currently active tab.

Steps to reproduce:
1. Open multiple tabs in the browser.
2. Select the leftmost tab.
3. Press Ctrl + T.

Expected result:
Have a new, empty tab next to the leftmost tab.

Actual result:
The new, empty tab opens next to the rightmost tab.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
Architecture: amd64
CheckboxSubmission: 09ae689090491ca53449589269e4bfd8
CheckboxSystem: edda5d4f616ca792bf437989cb597002
Date: Fri Apr 30 09:19:58 2010
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
 PATH=(custom, user)
 LANG=fi_FI.utf8
 SHELL=/bin/bash
SourcePackage: firefox

[Ria-klaassen (ria-klaassen)]

browser.tabs.insertRelatedAfterCurrent should do this. If this bug is filed for trunk, it should work in your build.

[Matěj Cepl (mcepl)]

browser.tabs.insertRelatedAfterCurrent seems to work just fine in 3.6 for Ctrl-<click>, but new tabs (opened with Ctrl-T) still opens in the far right.

[Shadowbottle (shadowbottle)]

Agreed, this is VERY irritating behavior. When I open up an empty tab I need it to open next to the tab I'm in currently. It's very disorienting to open up a new empty tab and be flown 15 tabs beyond where I just was. I'm always having to drag my new empty tab back to where I was working before.

This is very frustrating. Please fix.

[Rob-simpson (rob-simpson)]

Disagreed. If every new tab is opened next to the current tab, then the newly-opened tabs will be in the _wrong_ (backwards) order. For example, if you have the following tabs open already:

 Site A-Page 1, Site B-Page 1

and open additional pages that are all linked from the first page of Site B, they should appear in the following order:

 Site A-Page 1, Site B-Page 1, Site B-Page 2, Site B-Page 3, Site B-Page 4, etc.

NOT:

 Site A-Page 1, Site B-Page 1, Site B-Page 4, Site B-Page 3, Site B-Page 2, etc.

[Rob-simpson (rob-simpson)]

Of course, it could default to forward sequence, and give the user an option to put them in backwards sequence....

[Marco Kar.ma (makhellion)]

I want it too, I hope it can be done. Thanks for all your effort.

[Xtc4uall (xtc4uall)]

*** Bug 560469 has been marked as a duplicate of this bug. ***

[Paul (sabret00the)]

Opera is a great example of this working properly. At the moment it feels half implemented.

[Garikipati-sujitkumar (garikipati-sujitkumar)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

The build identifier for my FF is below:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

When there are multiple tabs opened on the browser and I try to open a new tab, a new tab is created at the right end of the existing tabs. I have read that the default behavior for this version is to open a tab immediate next to the current tab.

I tried modifying the browser.tabs.insertRelatedAfterCurrent flag in about:config file. But the behavior doesn't change even after modyifying the flag. So, this leaves the users with experiencing only one behavior of the browser.

Though some users prefer tabs to be opened at the end of all tabs, it would be better if this is configurable.

Reproducible: Always

Steps to Reproduce:
1.Open more than one tabs on the browser
2.Now, from the first tab, do google search for any word. Try to open any search result in a new tab.
3.A new tab will be opened at the end of the tabs list.
4.Now, open a new tab and type about:config in the address bar and press Enter.
5. In the filer bar type, 'browser.tabs.insertRelatedAfterCurrent'. A preference name 'browser.tabs.insertRelatedAfterCurrent' can be seen, change it's value by double clicking on it.
6. Restart the broswer and repeat steps 1,2. This should result in the observation stated in step 3
Actual Results:
New tab being opened at the end of all tabs. This eature can not be configured.

Expected Results:
New tab must be opened right next to the current tab. And this feature should be configurable.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

*** Bug 560641 has been marked as a duplicate of this bug. ***

[Jani Uusitalo (uusijani)]

Binary package hint: firefox

As the summary says: when a user opens a new, empty tab, it opens next to the rightmost of tabs currently open in the browser. This is inconsistent with the way links in new tabs are opened, which is to have them next to the currently active tab.

Steps to reproduce:
1. Open multiple tabs in the browser.
2. Select the leftmost tab.
3. Press Ctrl + T.

Expected result:
Have a new, empty tab next to the leftmost tab.

Actual result:
The new, empty tab opens next to the rightmost tab.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
Architecture: amd64
CheckboxSubmission: 09ae689090491ca53449589269e4bfd8
CheckboxSystem: edda5d4f616ca792bf437989cb597002
Date: Fri Apr 30 09:19:58 2010
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
 PATH=(custom, user)
 LANG=fi_FI.utf8
 SHELL=/bin/bash
SourcePackage: firefox

[Micah Gersten (micahg)]

Thank you for your bug report. I found the master upstream bug for this feature and linked it to this bug. Launchpad will import the upstream comments soon and you will be able to communicate with upstream if they ask any questions regarding this feature.
I'm going to mark it as Triaged and wait for upstream to work on this. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

[Lumbert (lumbert)]

Actually I often need a new blank tab next to that in which I'm currently browsing.

I'd like to see the following behavior for the NEW BLANK tabs.

If I want a new blank tab next to the current I just press "Ctrl-T".
If I want it in the far right end I click on the "Open a new tab" with my mouse.

This should be simple, logical and intuitive.

[Ws-bugzilla (ws-bugzilla)]

(In reply to comment #10)
> If I want a new blank tab next to the current I just press "Ctrl-T".
> If I want it in the far right end I click on the "Open a new tab" with my
> mouse.

I'd like both to be possible via keyboard shortcuts. I'd also love it if Ctrl+Click/Middle+Click were also controllable in a consistent way. E.g.:

- Ctrl+T - new tab to the right of current
- Ctrl+Shift+T - new tab all the way on the right
- Ctrl+Click - open in tab to the right of current (same for Middle+Click)
- Ctrl+Shift+Click - open in tab all the way to the right (same for Shift+Middle+Click)

[Remkodekeijzer (remkodekeijzer)]

(In reply to comment #11)
> (In reply to comment #10)
> > If I want a new blank tab next to the current I just press "Ctrl-T".
> > If I want it in the far right end I click on the "Open a new tab" with my
> > mouse.
>
> I'd like both to be possible via keyboard shortcuts. I'd also love it if
> Ctrl+Click/Middle+Click were also controllable in a consistent way. E.g.:
>
> - Ctrl+T - new tab to the right of current
> - Ctrl+Shift+T - new tab all the way on the right
> - Ctrl+Click - open in tab to the right of current (same for Middle+Click)
> - Ctrl+Shift+Click - open in tab all the way to the right (same for
> Shift+Middle+Click)
Which shortcut do you want to use for Undo Close tab? That is currently Ctrl+Shift+T.

[Ws-bugzilla (ws-bugzilla)]

Yeah, I've also realised that Ctrl+Shift+Click is also already taken.

Unfortunately I can't think of any consistent set that doesn't require at least one function to be remapped, so never mind.

[Matt (mdinger-bugzilla)]

Sounds like bug 262459.

[darkangel (lonedesign-2k)]

See "Tabs Open Relative" – https://addons.mozilla.org/en-US/firefox/addon/1956/

Unfortunately it hasn't been updated for the latest versions of Firefox.

This should be the default behaviour, IMHO.

[Paul (sabret00the)]

Could we at least get a preference, even if it's hidden, to enable the opening of new tabs relative to the current tab?

[Rob-simpson (rob-simpson)]

>> RC: Agreed, this is VERY irritating behavior. ... This is very frustrating. Please fix.

Agreed. Why is this so difficult, when opening tabs has been solved in other browsers, and many times in other apps.

It should be this simple, if you start with these tabs:

    AA BB CC XX YY ZZ

And open three new tabs from "CC", namely DD EE and FF, the result should be:

   AA BB CC DD EE FF XX YY ZZ

If the browser treats all the tabs as one group, then DD EE FF wind up _after_ XX YY ZZ, which appears to be the major complaint.

If it works right, you probably don't need an option to put the tab at the end or next to the current one, nor keyboard shortcuts for both, since if the XX YY ZZ group isn't there, the tabs will be going at the end anyway.

[Tehbaut (tehbaut)]

I'm not going to campaign for "new tabs opening next to the current tab" to be the *default* behavior of Firefox (though it makes sense as the default for related tabs, as is the case now in 3.6+), but it should definitely be a user configurable preference, even if only settable in the about:config preferences panel.

I personally do think that opening all new tabs next to the current tab ultimately makes sense. After all, it's easier to find and click on whichever tab you want to open a new one next to, than it is to open a new tab at the end then drag that tab to the ideal location, especially if you have tens or even hundreds of tabs open (not as uncommon as you might think). However, I think the general populace tends to prefer the current behavior of tabs opening at the end of the list, and if that is the case, then more users would be frustrated by new tabs opening next to the current tab than users who are currently frustrated by new tabs opening at the end of the tab bar, even with many of us latter folk are coming out of the shadows now that our favorite extension, Tabs Open Relative, was somehow killed by Firefox 3.6.2 (if I recall correctly) with no further updates by the developer(s) of said extension. Of course, if any of them are like myself, they also refuse to use any of the heavier extensions like the terrible Tab Mix Plus, or Tab Kit or Tabberwocky.

So as stated, I'm not asking for this requested behavior to be the default behavior. All I'm asking for is a simple about:config preference (such as browser.tabs.insertNewAfterCurrent) to compliment the existing preference for opening links in a new tab next to the current tab (browser.tabs.insertRelatedAfterCurrent).

To satisfy the presumed masses, the pref could default to:

browser.tabs.insertNewAfterCurrent = false

At least that way we tab opening snobs can change it (to true) to suit our preferences.

Don't forget that in addition to Ctrl/Cmd+T and the New Tab button, this should also be the behavior for new tabs opened via Alt+Enter via the Location Bar, as well as bookmarks and search, if preferences have indicated that either of the latter be opened in a new tab rather than the currently opened tab. While technically each of these could be their own preference (e.g. browser.tabs.insertSearchAfterCurrent) I'm thinking that anyone who wants this behavior would set each individual preference to true anyway, so that would probably be overkill.

I think that's all I have to say about that. Or maybe this is: PLEASE implement this in Firefox 4!!

[Euchre1 (euchre1)]

Although this seems to be partly resolved, it doesn't seem completely so. In the past I've used extensions to do this, and the new default behavior doesn't seem to behave as consistently as they did - and seems to disrupt those extensions from working properly as well.

The problem I observed with the implementation is that when you get past one level of relative tabs, the order goes all wonky. The child tab of a child tab doesn't seem to follow logic all the time, but I'll have to do some more strict tests to be sure I can provide conditions I can reproduce.

Another problem, however, is external links. An external link (passed by another application) is NOT relative to the current tab, but will be opened next to the current tab. I would prefer that external links be opened to the far right. This especially makes sense if the logic is that new blank tabs should be opened on the far right.

[Dao (dao)]

(In reply to comment #19)
> Another problem, however, is external links. An external link (passed by
> another application) is NOT relative to the current tab, but will be opened
> next to the current tab. I would prefer that external links be opened to the
> far right. This especially makes sense if the logic is that new blank tabs
> should be opened on the far right.

WFM

[Hskupin (hskupin)]

*** Bug 584459 has been marked as a duplicate of this bug. ***

[Paul (sabret00the)]

Can we set this to blocking the b5?

[Thefucci (thefucci)]

I am surprised there is no option for this. New tabs opening at the end of the tab bar is especially annoying when you've got 30 tabs open on a netbook. It's also plain annoying on any computer. Here's my vote :)

[Dietrich-mozilla (dietrich-mozilla)]

I agree, this is hurty for people with lots of tabs (me!), but it's not something we'd hold the entire release for, so blocking-.

[Stevewilliams (stevewilliams)]

(In reply to comment #18)
> I'm not going to campaign for "new tabs opening next to the current tab" to be
> the *default* behavior of Firefox (though it makes sense as the default for
> related tabs, as is the case now in 3.6+), but it should definitely be a user
> configurable preference, even if only settable in the about:config preferences
> panel.
>
> I personally do think that opening all new tabs next to the current tab
> ultimately makes sense. After all, it's easier to find and click on whichever
> tab you want to open a new one next to, than it is to open a new tab at the end
> then drag that tab to the ideal location, especially if you have tens or even
> hundreds of tabs open (not as uncommon as you might think). However, I think
> the general populace tends to prefer the current behavior of tabs opening at
> the end of the list, and if that is the case, then more users would be
> frustrated by new tabs opening next to the current tab than users who are
> currently frustrated by new tabs opening at the end of the tab bar, even with
> many of us latter folk are coming out of the shadows now that our favorite
> extension, Tabs Open Relative, was somehow killed by Firefox 3.6.2 (if I recall
> correctly) with no further updates by the developer(s) of said extension. Of
> course, if any of them are like myself, they also refuse to use any of the
> heavier extensions like the terrible Tab Mix Plus, or Tab Kit or Tabberwocky.
>
> So as stated, I'm not asking for this requested behavior to be the default
> behavior. All I'm asking for is a simple about:config preference (such as
> browser.tabs.insertNewAfterCurrent) to compliment the existing preference for
> opening links in a new tab next to the current tab
> (browser.tabs.insertRelatedAfterCurrent).
>
> To satisfy the presumed masses, the pref could default to:
>
> browser.tabs.insertNewAfterCurrent = false
>
> At least that way we tab opening snobs can change it (to true) to suit our
> preferences.
>
> Don't forget that in addition to Ctrl/Cmd+T and the New Tab button, this should
> also be the behavior for new tabs opened via Alt+Enter via the Location Bar, as
> well as bookmarks and search, if preferences have indicated that either of the
> latter be opened in a new tab rather than the currently opened tab. While
> technically each of these could be their own preference (e.g.
> browser.tabs.insertSearchAfterCurrent) I'm thinking that anyone who wants this
> behavior would set each individual preference to true anyway, so that would
> probably be overkill.
>
> I think that's all I have to say about that. Or maybe this is: PLEASE implement
> this in Firefox 4!!

Couldn't have said it better myself!

[Paul (sabret00the)]

Has it been decided to that this won't make it into Firefox 4 final? or does it still have a chance of making it in?

[Cork (cork)]

*** Bug 630988 has been marked as a duplicate of this bug. ***

[Larzfred (larzfred)]

So bad it takes so much time while it appears to me as an obvious ergonomic and essential feature. It has been reported more than a year ago, still not solved!

[Paul (sabret00the)]

With the new tab animation. We could have clicking the new tab button morp-out a new tab at the end of the tab line, but Ctrl/Cmd+T can open the tab next to the current tab as can opening new tab from the menu/app button.

[Christian Sasso (christian-sasso)]

tabnimation?
;)

(In reply to comment #29)
> With the new tab animation. We could have clicking the new tab button morp-out
> a new tab at the end of the tab line, but Ctrl/Cmd+T can open the tab next to
> the current tab as can opening new tab from the menu/app button.

[Hskupin (hskupin)]

*** Bug 655441 has been marked as a duplicate of this bug. ***

[Zfang (zfang)]

I can see this an add-on providing an option to open a new tab next to it on the current tab's context menu, but not a default for user. Since most of the user expect the new tab shows up near where they click the new tab button.

[Shadowbottle (shadowbottle)]

I had forgotten that the new tab button even existed since I use ctrl+n and cmd+n to open a new tab and completely remove the new tab button as it just clutters up space and takes up room for a more experienced user like myself. Perhaps two behaviors for either action - tab button press opens a new tab at the end, while ctrl+n or cmd+n generates one next to the tab the user is in?

It's wildly disorienting to have the new tab show up so far away from the tab you're using if you generate it using a keyboard shortcut. It's also particularly annoying when you need it to research something on the tab you're currently using as well - particularly if your desire is to compare the two pages.

::shrug::

[Dietrich-mozilla (dietrich-mozilla)]

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #32)
> Since most of
> the user expect the new tab shows up near where they click the new tab
> button.

Hi! Can you explain your rationale or show the evidence to support this claim?

[Fryn (fryn)]

(In reply to Dietrich Ayala (:dietrich) from comment #34)
> (In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #32)
> > Since most of
> > the user expect the new tab shows up near where they click the new tab
> > button.
>
> Hi! Can you explain your rationale or show the evidence to support this
> claim?

We make the new tab button look like a tab, so when the user clicks it, we lead the user to expect that the button will either transform into a new tab or produce a new tab from itself.

Also, as a general rule, I think buttons should produce visual feedback as close to themselves as possible; conversely, place buttons as close to their target of action as possible.

We (at least Limi and I) have considered/wanted having every new tab open next to the current tab, but this would require having a "plus" button be attached/adjacent to the current tab for the mapping to make sense visually, and I don't think we solved it in terms of visual design yet.

[Grgoffe (grgoffe)]

Hi,

I'm using a Nightly build at release(?)/version(?) 12.0a1 and this feature and a LOT of other things are working perfectly... There are, of course, features I don't use but I can not attest to them.

Regards,

George...

[Grgoffe (grgoffe)]

I should clarify my previous post a tiny bit. I use the middle button on links to get a tab next to the one I'm currently using, ctrl-t gives a new tab at the end of the "tab bar".

[Felipe Gasper (felipegasper)]

George: This case has basically become about “finishing the job” that insertRelatedAfterCurrent started.

The others here and I seem generally to believe that *all* new tabs should be able to open to the right of the current tab. Whether multiple consecutive new tabs open up right-to-left or left-to-right is, IMO, a minor issue.

The major point is that the current behavior, whereby all CTRL-T new tabs open to the extreme right, is very frustrating for many of us.

Tab Utilities and Tab Utilities Lite allow this, by the way. (But they’re not updated for FF10 yet…)

[Grgoffe (grgoffe)]

Felipe,

Thank you for your kind comments and consideration.

George...

[Eoghanmurray (eoghanmurray)]

There is a lot of discussion here about buttons and tab ordering; I think they all work fine as they are; it's just the behaviour of the keyboard shortcut (CTRL+T) that is jarring.

Pressing CTRL+T when at Tab 3 and having the tab bar scroll to the new tab at position 21 is extremely distracting and immediately takes me out of my 'flow'.

[Chrcoluk (chrcoluk)]

its sad we continue to see usueless changes to the app (many which are regressions) yet 3 years a later a simole option to have new tabs next to current still doesnt exist.

[Grgoffe (grgoffe)]

Chris,

I have a Fedora 19 system here and have used the middle mouse button on a link in the current tab to make a tab next to the current tab.

Of course, I then have to replace the URL but at least it works...

George...

[Kyle Dobbs (kyle-dobbs)]

As has already been said, it's sad that this hasn't been addressed. "Use an addon" is not a good answer to a deficit in core browser functionality.

[Mikalra (mikalra)]

Agreed: this shoot-to-the-far-right behavior is extremely annoying, especially when I want to refer back and forth from information in the new tab when focused on the original tab. PLEASE implement this change, and also roll it over for Seamonkey ASAP thereafter.

[Luke-mele (luke-mele)]

This add-on works for me for Firefox Nightlies:

https://addons.mozilla.org/en-US/firefox/addon/tab-control/

Although no longer maintained it still works perfect for setting new tab next to current.

And yes I hope we do get the option in the future to set this in about:config instead of relying on an extension.

[Aeidein (aeidein)]

I think this might even be good enough to be considered for default behavior — I suspect opening next to the current one would be less confusing and more convenient for most users.

[Jim Michaels (jmichae3-yahoo)]

https://bugzilla.mozilla.org/show_bug.cgi?id=790531
my suggestion combined with someone else's is in addition to the + button was to right click on a tab and have a context menu items:
insert tab &Left
insert tab &Right

I like the flexibility of th4e other person's bug report, and I like the context menu thing, which also could possibly be made available via the keyboard as a hotkey(?).

[William Oprandi (woprandi)]

I think also an option would be the best compromise for this need

[David Rankin (drankinatty)]

I would suggest tabs opening next to the current being the default, except for 'app tabs'. Pinned app tab order should not be disturbed by subsequent tab opening.

[Grgoffe (grgoffe)]

I'd like to add to this bug by suggesting in general that as many options as possible be given to the user. Out of the box could work the same as always but those who want to change will have the ability.

[Bohr Shaw (bohrshaw)]

AFAIK, there are currently two ways to open a new tab with a typed URL using keyboard shortcuts:
"Ctrl-T" which is the equivalent of clicking the new tab icon, and "Alt-Enter" in the location bar.

The both are different but kind of duplicate ways to achieve the same purpose. And regarding to my fervent need to open a new tab next to the current, I propose to let "Alt-Enter" do this job. Moreover, it's natural to regard a new tab opened by Alt-Enter as a related tab to the current. Thus it's probably should be included in the realm of "browser.tabs.insertRelatedAfterCurrent".

[Grgoffe (grgoffe)]

Hi,

More information about this topic that seem to be solved for me by a plug-in named "Tab mix plus" at this web site. It's pretty cool. Way beyond what I would have asked for. I had a little trouble understanding the behavior of one of the options and their support staff was MOST happy and ABLE to help me. I would give them a 10 out of 10.

Thanks,

George...

[Asdfjohns (asdfjohns)]

i worked around this by creating a bookmarklet with location set to "javascript:window.open('about:blank');void(0);" and assigning a keyword to it, 't' in my case.

if i need a new tab next to the current, i either click the bookmarklet or type 'ctrl+l', 't', 'return'.

i hope this helps some of you who might not want to install an addon for basic functionality.

i would still prefer an option to enable this behaviour natively.

[Grgoffe (grgoffe)]

There is an add-on called "tab mix plus" that does this and a WHOLE LOT OF OTHER TAB related things. Check it out if you want?

[Emailmeat (emailmeat)]

(In reply to George R. Goffe from comment #54)
> There is an add-on called "tab mix plus" that does this and a WHOLE LOT OF
> OTHER TAB related things. Check it out if you want?

I reckon that everybody who has an account on this bug tracker is already familiar with Tab Mix Plus. The point is that we shouldn't need to install extensions for such basic functionality.

[Grgoffe (grgoffe)]

Hi,

I completely agree with the sentiment expressed above... It IS hard for software to do EVERYTHING though. The reason for my post was to attempt to let "everyone" know about tab mix plus. It has some GREAT ideas.

Thanks for your post.

George..

[Aenosedney (aenosedney)]

Broken in the latest Nightly build (as of today) I had both Tab Mix Plus and Tab Control installed to rectify this problem, and both are no longer working. This functionality really needs to be built-in to Firefox by default.

[Plurtu (plurtu)]

Created attachment 8642998
middlemouse on new tab button creates a new tab related to current

Workarounds involve duplicating the current tab or opening a link in a new related tab but these don't show the new tab page and are less responsive.

Ideally there should be a context menu entry like other browsers (Chrome, IE11) but considering that adding a "Duplicate Tab" entry was opposed (Bug 455722) it looks like we have to resort to other methods. The middlemouse approach (Bug 448546) seems like a valid alternative and is currently unutilized for the new tab button.

Here's a patch to make middlemouse/ctrl-click on the new tab button create a new tab related to the current tab.

It uses whereToOpenLink() so it is consistent with other middlemouse usage.
It uses standard related tab behavior, adding the new tab after other related tabs.
It needs to exclude commands that originate from keypresses so that Ctrl+T behaves normally.

[Dao+bmo (dao+bmo)]

Comment on attachment 8642998
middlemouse on new tab button creates a new tab related to current

Let's get ui-review first

[T-philipp (t-philipp)]

Comment on attachment 8642998
middlemouse on new tab button creates a new tab related to current

Sounds like a sensible shortcut if I understand this correctly: So with this patch, middle-clicking the new tab button in the tab strip will create a new tab next to the currently selected tab instead of at the end of the tab strip, correct?
If so, go for it! :)

[Petr 'PePa' Pavel (petr.pavel)]

I never need to open a new tab (blank or from a link) at the end of the tab panel. Also, I don't have a middle button. So I'd appreciate a configuration option that would make the "open next to current" behaviour default.

[Plurtu (plurtu)]

Comment on attachment 8642998
middlemouse on new tab button creates a new tab related to current

Review of attachment 8642998:
-----------------------------------------------------------------

That's correct, will need a push to try.

[Hzbz (hzbz)]

People looking for an always-on solution...

I wrote an add-on called Always Right which always opens any new tab immediately adjacent to the right of current tab:

https://addons.mozilla.org/en-us/firefox/addon/always-right/

For how I use the Web, this is correct behavior 100% of the time.

[Petr 'PePa' Pavel (petr.pavel)]

(In reply to Dietrich Ayala (:dietrich) from comment #63)
> People looking for an always-on solution...
> https://addons.mozilla.org/en-us/firefox/addon/always-right/

I use this one:
https://addons.mozilla.org/en-US/firefox/addon/open-tabs-next-to-current/

[Dao+bmo (dao+bmo)]

Comment on attachment 8642998
middlemouse on new tab button creates a new tab related to current

>+ // Make new tab related to current except for key commands
>+ if (((where == "tab") || (where == "tabshifted")) &&
>+ (!event.sourceEvent || event.sourceEvent.target.localName != "key")) {
>+ openUILinkIn(BROWSER_NEW_TAB_URL, "tab", {relatedToCurrent: true,
>+ inBackground: where == "tabshifted"});
>+ } else if (where == "window") {
> OpenBrowserWindow();
> } else {
> BrowserOpenTab();
> }
> }

Could this be simplified by also calling openUILinkIn in the default case instead of BrowserOpenTab? E.g.:

> if (where == "window") {
> OpenBrowserWindow();
> } else {
> let relatedToCurrent = (where == "tab" || where == "tabshifted") &&
> (!event.sourceEvent || event.sourceEvent.target.localName != "key");
> let inBackground = relatedToCurrent && where == "tabshifted";
> openUILinkIn(BROWSER_NEW_TAB_URL, "tab", {relatedToCurrent: relatedToCurrent,
> inBackground: inBackground});
> }

I'm also not sure I understand the "except for key commands" logic. Is there no way to explicitly filter for mouse events here?

[Michaelaccountsly (michaelaccountsly)]

(In reply to Dietrich Ayala (:dietrich) from comment #63)

> I wrote an add-on called Always Right which always opens any new tab
> immediately adjacent to the right of current tab:
>
> https://addons.mozilla.org/en-us/firefox/addon/always-right/

Unfortunately, this addon (and the one suggested by Pietr) currently only works on Firefox; I use Seamonkey. It's my understanding that almost everything that can be done on FF can be transferred to SM with a relatively simple due diligence:
http://geckoisgecko.org/

... tho' this is for the website itself, not add-ons. It would be great if you could tweak this for SM users (and, of course, if the fine coder volunteers for FF & SM would build this functionality into the browser, as the default or as a preference).

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

Stealing per IRC.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

Created attachment 8781962
middlemouse on new tab button should create a new tab related to current,

Refactored as suggested, and added a comment why we're using the target of the source event.

[Dao+bmo (dao+bmo)]

Comment on attachment 8781962
middlemouse on new tab button should create a new tab related to current,

> function BrowserOpenNewTabOrWindow(event) {
>- if (event.shiftKey) {
>+ let where = whereToOpenLink(event);
>+ if (where == "window") {
> OpenBrowserWindow();
> } else {
>- BrowserOpenTab();
>+ // Make new tab related to current except when created via a shortcut <key> command.

This comment doesn't seem accurate, e.g. we don't want to open the tab related to the current one for plain clicks... right?

>+ let sourceNotKeyEvent = !event.sourceEvent || event.sourceEvent.target.localName != "key";
>+ let relatedToCurrent = (where == "tab" || where == "tabshifted") && sourceNotKeyEvent;
>+ openUILinkIn(BROWSER_NEW_TAB_URL, "tab", {relatedToCurrent,
>+ inBackground: where == "tabshifted"});

I'm somewhat confused by this. Why are you not passing through "tabshifted" as openUILinkIn's 'where' argument?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to Dão Gottwald [:dao] from comment #69)
> Comment on attachment 8781962
> middlemouse on new tab button should create a new tab related to current,
>
> > function BrowserOpenNewTabOrWindow(event) {
> >- if (event.shiftKey) {
> >+ let where = whereToOpenLink(event);
> >+ if (where == "window") {
> > OpenBrowserWindow();
> > } else {
> >- BrowserOpenTab();
> >+ // Make new tab related to current except when created via a shortcut <key> command.
>
> This comment doesn't seem accurate, e.g. we don't want to open the tab
> related to the current one for plain clicks... right?
>
> >+ let sourceNotKeyEvent = !event.sourceEvent || event.sourceEvent.target.localName != "key";
> >+ let relatedToCurrent = (where == "tab" || where == "tabshifted") && sourceNotKeyEvent;
> >+ openUILinkIn(BROWSER_NEW_TAB_URL, "tab", {relatedToCurrent,
> >+ inBackground: where == "tabshifted"});
>
> I'm somewhat confused by this. Why are you not passing through "tabshifted"
> as openUILinkIn's 'where' argument?

I literally just used the suggestion you gave in comment #65. I can't just pass "tab" because in some cases where == "current". I'll rewrite to use a ternary and drop the inBackground prop, I guess? I'm fairly sure there will be no behavioural difference compared to the current patch.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to :Gijs Kruitbosch (PTO recovery mode) from comment #70)
> (In reply to Dão Gottwald [:dao] from comment #69)
> > >+ let sourceNotKeyEvent = !event.sourceEvent || event.sourceEvent.target.localName != "key";
> > >+ let relatedToCurrent = (where == "tab" || where == "tabshifted") && sourceNotKeyEvent;
> > >+ openUILinkIn(BROWSER_NEW_TAB_URL, "tab", {relatedToCurrent,
> > >+ inBackground: where == "tabshifted"});
> >
> > I'm somewhat confused by this. Why are you not passing through "tabshifted"
> > as openUILinkIn's 'where' argument?
>
> I literally just used the suggestion you gave in comment #65. I can't just
> pass "tab" because in some cases where == "current".

I meant, I can't just pass |where|.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

Created attachment 8782084
middlemouse on new tab button should create a new tab related to current,

MozReview-Commit-ID: DOxw0CGpRcp

[Dao+bmo (dao+bmo)]

Created attachment 8782846
patch v4

Your patch still hurts my brain and I couldn't help thinking this could be simplified further, so I took a shot at rewriting it myself. I realize this changes behavior for the "window" case.

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

Comment on attachment 8782846
patch v4

Review of attachment 8782846:
-----------------------------------------------------------------

Meh. r+ I guess? I'm not sure why this is "simpler", but obviously it works, so whatever.

As far as the "window" case is concerned, you're explicitly regressing bug 644186, but you reviewed that and it never had ui-review, so up to you if you think you need it here.

::: browser/base/content/browser.js
@@ -7839,5 @@
> }
> }
> };
>
> -function BrowserOpenNewTabOrWindow(event) {

This method is referenced by a number of add-ons including but not limited to tabmixplus. We probably need to list it in the compat notes.

[Dao+bmo (dao+bmo)]

(In reply to :Gijs Kruitbosch from comment #74)
> Meh. r+ I guess? I'm not sure why this is "simpler", but obviously it works,
> so whatever.

Mostly because it avoids this blob of spaghetti code:

+ let sourceNotKeyEvent = !event.sourceEvent || event.sourceEvent.target.localName != "key";
+ let relatedToCurrent = (where == "tab" || where == "tabshifted") && sourceNotKeyEvent;
+ openUILinkIn(BROWSER_NEW_TAB_URL, where == "tabshifted" ? where : "tab",
+ {relatedToCurrent});

Comment 65 was just a quick suggestion to streamline the logic a bit. I didn't say "please rewrite exactly like this to make this code awesome." So unfortunately, I still find the above hard to read. Code where you need to concentrate for a minute to decipher the structure is likely bad code. (Except for well-written regular expressions. I love regular expressions. :>)

[Pulsebot (pulsebot)]

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cd5beac45eac
Let accel-click and middle-click on the new tab button open a new tab next to the current one. r=gijs

[KWierso (kwierso)]

https://hg.mozilla.org/mozilla-central/rev/cd5beac45eac

[Sahmi-soulaimane (sahmi-soulaimane)]

Although the status says FIXED the keyboard shortcut `Ctrl+T` (which I use most) still doesn't work as expected.
I am using firefox 54.0a2.

[Grgoffe (grgoffe)]

Hi,

I gave up on trying to get these options "fixed" so I started using an add-on named "Tab Mix Plus". This add-on has a setting in it's preferences that traverses ctrl-t navigates tabs in the most recently used order. Somehow that was set... it was driving me NUTS! It has some really nice features.

George...

[Albert-3 (albert-3)]

(In reply to سليمان السهمي (Soulaïman Sahmi) from comment #78)
> Although the status says FIXED the keyboard shortcut `Ctrl+T` (which I use
> most) still doesn't work as expected.
> I am using firefox 54.0a2.

you can also try https://addons.mozilla.org/en-US/firefox/addon/always-right/

[Michaelaccountsly (michaelaccountsly)]

This bug is definitely not fixed, either in FF 51 (I have FF52, and there's no solution there) or in Seamonkey. And unfortunately, the suggested addons are FF-only. I would still like to see a solution ...

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

(In reply to سليمان السهمي (Soulaïman Sahmi) from comment #78)
> Although the status says FIXED the keyboard shortcut `Ctrl+T` (which I use
> most) still doesn't work as expected.

(In reply to Michael from comment #81)
> This bug is definitely not fixed, either in FF 51 (I have FF52, and there's
> no solution there) or in Seamonkey. And unfortunately, the suggested addons
> are FF-only. I would still like to see a solution ...

This bug is specifically about middle-clicking or modifier-clicking the actual button, not about what happens if you use the keyboard shortcut, or what happens if you click the button with the left mouse button without using any modifier keys on the keyboard, and this bug is specific to Firefox.

If you want to change keyboard behaviour, or want to see a change in seamonkey, or the *specific* changes I just outlined don't work for you (check in a clean profile to make sure add-ons like tabmixplus aren't changing the behaviour), file a new bug. Commenting here will not help.

[Michaelaccountsly (michaelaccountsly)]

(In reply to :Gijs from comment #82)
>
> This bug is specifically about middle-clicking or modifier-clicking the
> actual button [...] and this bug is specific to Firefox.

Huh ... OK, yes, that works, as far as it goes ;) . I see that you're the person who designed the patch, Gijs: thanks for your efforts, and secondarily Dão Gottwald and others.

> If you want to change keyboard behaviour, or want to see a change in
> seamonkey [...] file a new bug. Commenting here will not help.

Shall do ...

[Klaus-5 (klaus-5)]

For anyone coming this way: set browser.tabs.insertAfterCurrent in about:config to true