528005 - Let accel-click and middle-click on the new tab button open a new tab next to the current one

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, enhancement)

Description

[Thomas D. (:thomas8)]

With many tabs, FF currently opens links or new tab somewhere at the far end of all tabs. Especially for links that are related to the current page, that's very inconvenient as user needs to drag newly opened tab all the way back to place it beside the current tab. There should be some way of opening links/new tabs right next to the current tab (probably a pref).

Comment 1

[Ria Klaassen (not reading all bugmail)]

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

Comment 2

[Matěj Cepl]

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.

Comment 3

[RC]

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.

Comment 4

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

Comment 5

[Rob Simpson]

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

Comment 6

[Karma]

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

Comment 8

[Paul [pwd]]

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

Comment 10

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

Comment 11

[Roman]

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

Comment 12

[Remko de Keijzer]

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

Comment 13

[Roman]

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.

Comment 14

[Matt]

Sounds like bug 262459.

Comment 15

[Glen A.]

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.

Comment 16

[Paul [pwd]]

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

Comment 17

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

Comment 18

[Trig Tehbau]

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!!

Comment 19

[Euchre]

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.

Comment 20

[Dão Gottwald [: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

Comment 22

[Paul [pwd]]

Can we set this to blocking the b5?

Comment 23

[soandso]

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 :)

Comment 24

[Dietrich Ayala (:dietrich)]

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

Comment 25

[Steve]

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

Comment 26

[Paul [pwd]]

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?

Comment 28

[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!

Comment 29

[Paul [pwd]]

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.

Comment 30

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

Comment 32

[Zhenshuo Fang (:fang) - Firefox UX Team]

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.

Comment 33

[RC]

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::

Comment 34

[Dietrich Ayala (:dietrich)]

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

Comment 35

[Frank Yan (: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.

Comment 36

[George R. Goffe]

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

Comment 37

[George R. Goffe]

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

Comment 38

[Felipe]

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…)

Comment 39

[George R. Goffe]

Felipe,

Thank you for your kind comments and consideration.

George...

Comment 40

[Eoghan Murray]

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

Comment 41

[Chris]

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.

Comment 42

[George R. Goffe]

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

Comment 43

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

Comment 44

[[e-mail]]

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.

Comment 45

[Luke]

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.

Comment 46

[merfius]

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.

Comment 47

[Jim Michaels]

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

Comment 48

[woprandi]

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

Comment 49

[David Rankin]

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.

Comment 50

[George R. Goffe]

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.

Comment 51

[Bohr Shaw]

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

Comment 52

[George R. Goffe]

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

Comment 53

[foo]

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.

Comment 54

[George R. Goffe]

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?

Comment 55

[08xjcec48]

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

Comment 56

[George R. Goffe]

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

Comment 57

[Aeed]

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.

Comment 58

[Kestrel]

Attachment: 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.

Comment 59

[Dão Gottwald [:dao]]

Comment on attachment 8642998 [details] [diff] [review]
middlemouse on new tab button creates a new tab related to current

Let's get ui-review first

Comment 60

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Comment on attachment 8642998 [details] [diff] [review]
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! :)

Comment 61

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

Comment 62

[Kestrel]

Comment on attachment 8642998 [details] [diff] [review]
middlemouse on new tab button creates a new tab related to current

Review of attachment 8642998 [details] [diff] [review]:
-----------------------------------------------------------------

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

Comment 63

[Dietrich Ayala (:dietrich)]

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.

Comment 64

[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/

Comment 65

[Dão Gottwald [:dao]]

Comment on attachment 8642998 [details] [diff] [review]
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?

Comment 66

[[e-mail]]

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

Comment 67

[:Gijs (he/him)]

Stealing per IRC.

Comment 68

[:Gijs (he/him)]

Attachment: 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.

Comment 69

[Dão Gottwald [:dao]]

Comment on attachment 8781962 [details] [diff] [review]
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?

Comment 70

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #69)
> Comment on attachment 8781962 [details] [diff] [review]
> 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.

Comment 71

[:Gijs (he/him)]

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

Comment 72

[:Gijs (he/him)]

Attachment: middlemouse on new tab button should create a new tab related to current,

MozReview-Commit-ID: DOxw0CGpRcp

Comment 73

[Dão Gottwald [:dao]]

Attachment: 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.

Comment 74

[:Gijs (he/him)]

Comment on attachment 8782846 [details] [diff] [review]
patch v4

Review of attachment 8782846 [details] [diff] [review]:
-----------------------------------------------------------------

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.

Comment 75

[Dão Gottwald [:dao]]

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

Comment 76

[Pulsebot]

Pushed by [e-mail]:
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

Comment 77

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 78

[سليمان السهمي (Soulaïman Sahmi)]

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.

Comment 79

[George R. Goffe]

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

Comment 80

[Albert Scheiner [:alberts]]

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

Comment 81

[[e-mail]]

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

Comment 82

[:Gijs (he/him)]

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

Comment 83

[[e-mail]]

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

Comment 84

[klaus]

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