Last Comment Bug 528005 - Let accel-click and middle-click on the new tab button open a new tab next to the current one
: Let accel-click and middle-click on the new tab button open a new tab next to...
Status: RESOLVED FIXED
: addon-compat
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
-- enhancement with 67 votes (vote)
: Firefox 51
Assigned To: Dão Gottwald [:dao]
:
: Dão Gottwald [:dao]
Mentors:
: 560469 560641 584459 630988 655441 (view as bug list)
Depends on:
Blocks: cuts-tabs 565549 1327284 1331595 1325014
  Show dependency treegraph
 
Reported: 2009-11-11 12:43 PST by Thomas D. (currently busy elsewhere; needinfo?me)
Modified: 2017-02-07 04:13 PST (History)
70 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
-


Attachments
middlemouse on new tab button creates a new tab related to current (1.08 KB, patch)
2015-08-04 04:32 PDT, Kestrel
philipp: ui‑review+
Details | Diff | Splinter Review
middlemouse on new tab button should create a new tab related to current, (2.20 KB, patch)
2016-08-17 04:39 PDT, :Gijs
no flags Details | Diff | Splinter Review
middlemouse on new tab button should create a new tab related to current, (2.23 KB, patch)
2016-08-17 11:16 PDT, :Gijs
no flags Details | Diff | Splinter Review
patch v4 (3.83 KB, patch)
2016-08-19 03:36 PDT, Dão Gottwald [:dao]
gijskruitbosch+bugs: review+
Details | Diff | Splinter Review

Description User image Thomas D. (currently busy elsewhere; needinfo?me) 2009-11-11 12:43:34 PST
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 User image Ria Klaassen (not reading all bugmail) 2009-11-11 14:51:41 PST
browser.tabs.insertRelatedAfterCurrent should do this. If this bug is filed for trunk, it should work in your build.
Comment 2 User image Matěj Cepl 2010-01-29 02:23:41 PST
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 User image RC 2010-02-17 15:27:28 PST
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 User image Rob Simpson 2010-03-17 12:03:28 PDT
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 User image Rob Simpson 2010-03-17 12:04:47 PDT
Of course, it could default to forward sequence, and give the user an option to put them in backwards sequence....
Comment 6 User image Karma 2010-03-26 17:36:54 PDT
I want it too, I hope it can be done. Thanks for all your effort.
Comment 7 User image (mostly gone) XtC4UaLL [:xtc4uall] 2010-04-20 04:32:29 PDT
*** Bug 560469 has been marked as a duplicate of this bug. ***
Comment 8 User image Paul [pwd] 2010-04-20 05:00:57 PDT
Opera is a great example of this working properly. At the moment it feels half implemented.
Comment 9 User image Micah Gersten 2010-04-29 23:59:05 PDT
*** Bug 560641 has been marked as a duplicate of this bug. ***
Comment 10 User image lumbert 2010-05-01 04:18:46 PDT
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 User image Roman 2010-05-13 04:10:49 PDT
(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 User image Remko de Keijzer 2010-05-13 14:08:24 PDT
(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 User image Roman 2010-05-13 15:37:47 PDT
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 User image mdinger.bugzilla@gmail.com 2010-06-21 14:15:19 PDT
Sounds like bug 262459.
Comment 15 User image Glen A. 2010-06-23 02:56:18 PDT
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 User image Paul [pwd] 2010-06-30 03:34:13 PDT
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 User image Rob Simpson 2010-07-19 07:29:08 PDT
>> 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 User image Trig Tehbau 2010-07-21 01:49:57 PDT
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 User image Euchre 2010-07-28 02:28:38 PDT
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 User image Dão Gottwald [:dao] 2010-07-28 06:09:01 PDT
(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 21 User image Henrik Skupin (:whimboo) [away 02/18 - 02/27] 2010-08-04 14:57:14 PDT
*** Bug 584459 has been marked as a duplicate of this bug. ***
Comment 22 User image Paul [pwd] 2010-08-19 01:16:15 PDT
Can we set this to blocking the b5?
Comment 23 User image soandso 2010-09-05 18:28:34 PDT
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 User image Dietrich Ayala (:dietrich) 2010-09-07 04:44:50 PDT
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 User image Steve 2010-09-08 17:30:49 PDT
(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 User image Paul [pwd] 2010-12-11 09:28:27 PST
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 27 User image Cork 2011-02-02 12:49:44 PST
*** Bug 630988 has been marked as a duplicate of this bug. ***
Comment 28 User image larzfred 2011-02-02 12:56:03 PST
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 User image Paul [pwd] 2011-04-27 14:41:19 PDT
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 User image Christian Sasso 2011-04-27 15:13:54 PDT
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 31 User image Henrik Skupin (:whimboo) [away 02/18 - 02/27] 2011-05-09 13:30:51 PDT
*** Bug 655441 has been marked as a duplicate of this bug. ***
Comment 32 User image Zhenshuo Fang (:fang) - Firefox UX Team 2012-01-27 15:20:35 PST
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 User image RC 2012-01-27 15:32:35 PST
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 User image Dietrich Ayala (:dietrich) 2012-01-27 15:48:03 PST
(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 User image Frank Yan (:fryn) 2012-01-27 15:55:40 PST
(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 User image George R. Goffe 2012-01-28 06:26:12 PST
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 User image George R. Goffe 2012-01-28 06:29:32 PST
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 User image Felipe 2012-02-02 15:30:17 PST
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 User image George R. Goffe 2012-02-02 17:19:46 PST
Felipe,

Thank you for your kind comments and consideration.

George...
Comment 40 User image Eoghan Murray 2012-04-17 05:34:03 PDT
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 User image Chris 2013-12-12 15:26:21 PST
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 User image George R. Goffe 2013-12-12 16:08:22 PST
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 User image Kyle Dobbs 2014-01-29 14:19:26 PST
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 User image Michael 2014-02-11 03:04:24 PST
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 User image Luke 2014-02-17 09:59:59 PST
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 User image merfius 2014-03-07 06:42:45 PST
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 User image Jim Michaels 2014-03-10 12:46:33 PDT
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 User image woprandi 2014-08-18 15:19:43 PDT
I think also an option would be the best compromise for this need
Comment 49 User image David Rankin 2014-09-05 23:31:36 PDT
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 User image George R. Goffe 2014-10-15 11:15:31 PDT
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 User image Bohr Shaw 2014-12-26 17:51:33 PST
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 User image George R. Goffe 2015-01-14 14:01:32 PST
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 User image foo 2015-03-17 17:00:50 PDT
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 User image George R. Goffe 2015-05-29 01:16:30 PDT
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 User image Hide my Email 2015-05-29 09:55:23 PDT
(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 User image George R. Goffe 2015-05-29 16:27:09 PDT
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 User image Aeed 2015-08-01 05:06:07 PDT
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 User image Kestrel 2015-08-04 04:32:58 PDT
Created attachment 8642998 [details] [diff] [review]
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 User image Dão Gottwald [:dao] 2015-08-04 09:27:06 PDT
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 User image (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo 2015-08-05 03:57:11 PDT
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 User image petr.pavel 2015-08-05 04:05:36 PDT
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 User image Kestrel 2015-08-11 04:55:28 PDT
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 User image Dietrich Ayala (:dietrich) 2015-08-11 14:34:22 PDT
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 User image petr.pavel 2015-08-12 02:35:03 PDT
(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 User image Dão Gottwald [:dao] 2015-08-19 05:39:42 PDT
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 User image Michael 2015-08-19 20:38:54 PDT
(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 User image :Gijs 2016-08-16 08:38:47 PDT
Stealing per IRC.
Comment 68 User image :Gijs 2016-08-17 04:39:39 PDT
Created attachment 8781962 [details] [diff] [review]
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 User image Dão Gottwald [:dao] 2016-08-17 08:37:45 PDT
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 User image :Gijs 2016-08-17 09:56:45 PDT
(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 User image :Gijs 2016-08-17 09:57:23 PDT
(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 User image :Gijs 2016-08-17 11:16:14 PDT
Created attachment 8782084 [details] [diff] [review]
middlemouse on new tab button should create a new tab related to current,

MozReview-Commit-ID: DOxw0CGpRcp
Comment 73 User image Dão Gottwald [:dao] 2016-08-19 03:36:37 PDT
Created attachment 8782846 [details] [diff] [review]
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 User image :Gijs 2016-08-19 04:35:46 PDT
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 User image Dão Gottwald [:dao] 2016-08-19 05:24:58 PDT
(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 User image Pulsebot 2016-08-19 05:28:25 PDT
Pushed by dgottwald@mozilla.com:
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 User image Wes Kocher (:KWierso) 2016-08-19 18:18:25 PDT
https://hg.mozilla.org/mozilla-central/rev/cd5beac45eac

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