The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Firefox 51

Status

()

Firefox
Tabbed Browser
--
enhancement
RESOLVED FIXED
8 years ago
2 months ago

People

(Reporter: Thomas D. (currently busy elsewhere; needinfo?me), Assigned: dao)

Tracking

(Blocks: 4 bugs, {addon-compat})

Trunk
Firefox 51
addon-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox51 fixed, blocking2.0 -)

Details

Attachments

(1 attachment, 3 obsolete attachments)

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).
browser.tabs.insertRelatedAfterCurrent should do this. If this bug is filed for trunk, it should work in your build.

Comment 2

7 years ago
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.
Component: General → Tabbed Browser
QA Contact: general → tabbed.browser

Comment 3

7 years ago
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

7 years ago
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

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

Comment 6

7 years ago
I want it too, I hope it can be done. Thanks for all your effort.
Duplicate of this bug: 560469

Comment 8

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

Updated

7 years ago
Duplicate of this bug: 560641

Updated

7 years ago

Comment 10

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

Updated

7 years ago
Blocks: 565549

Updated

7 years ago
Blocks: 565515

Comment 11

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

Updated

7 years ago
Blocks: 565621

Comment 12

7 years ago
(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

7 years ago
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.
Sounds like bug 262459.

Comment 15

7 years ago
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

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

Updated

7 years ago
Assignee: nobody → fyan
Status: NEW → ASSIGNED
Summary: Provide ways of opening links / new tab next to the current tab (besides, near, to the right of current tab) → Provide ways of opening new tabs next to the current tab

Updated

7 years ago
No longer blocks: 565621

Comment 17

7 years ago
>> 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

7 years ago
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

7 years ago
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.
(Assignee)

Comment 20

7 years ago
(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
Duplicate of this bug: 584459

Comment 22

7 years ago
Can we set this to blocking the b5?
blocking2.0: --- → ?

Updated

7 years ago
Assignee: fryn → nobody
Status: ASSIGNED → NEW

Comment 23

7 years ago
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 :)
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-.
blocking2.0: ? → -
Keywords: uiwanted

Comment 25

7 years ago
(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

6 years ago
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?

Updated

6 years ago
Duplicate of this bug: 630988

Comment 28

6 years ago
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

6 years ago
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

6 years ago
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.
Duplicate of this bug: 655441
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.
Keywords: uiwanted

Comment 33

5 years ago
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::
(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

5 years ago
(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

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
Felipe,

Thank you for your kind comments and consideration.

George...

Comment 40

5 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
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

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

Comment 49

3 years ago
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

3 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
(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

2 years ago
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..
Keywords: uiwanted

Comment 57

2 years ago
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

2 years ago
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.
Attachment #8642998 - Flags: review?(gavin.sharp)
Attachment #8642998 - Flags: review?(gavin.sharp) → review?(dao)
(Assignee)

Comment 59

2 years ago
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
Attachment #8642998 - Flags: review?(dao) → ui-review?(philipp)
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! :)
Attachment #8642998 - Flags: ui-review?(philipp) → ui-review+

Comment 61

2 years ago
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

2 years ago
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.
Attachment #8642998 - Flags: review?(dao)
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

2 years ago
(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/
(Assignee)

Comment 65

2 years ago
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?
Attachment #8642998 - Flags: review?(dao)

Comment 66

2 years ago
(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).
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Keywords: uiwanted

Comment 67

7 months ago
Stealing per IRC.
Assignee: jaws → gijskruitbosch+bugs

Comment 68

7 months ago
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.
Attachment #8781962 - Flags: review?(dao+bmo)
(Assignee)

Comment 69

7 months ago
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?
Attachment #8781962 - Flags: review?(dao+bmo)

Comment 70

7 months ago
(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

7 months ago
(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

7 months ago
Created attachment 8782084 [details] [diff] [review]
middlemouse on new tab button should create a new tab related to current,

MozReview-Commit-ID: DOxw0CGpRcp
Attachment #8782084 - Flags: review?(dao+bmo)

Updated

7 months ago
Attachment #8781962 - Attachment is obsolete: true
(Assignee)

Comment 73

7 months ago
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.
Attachment #8782846 - Flags: review?(gijskruitbosch+bugs)

Comment 74

7 months ago
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.
Attachment #8782846 - Flags: review?(gijskruitbosch+bugs) → review+

Updated

7 months ago
Attachment #8782084 - Attachment is obsolete: true
Attachment #8782084 - Flags: review?(dao+bmo)

Updated

7 months ago
Attachment #8642998 - Attachment is obsolete: true

Updated

7 months ago
Assignee: gijskruitbosch+bugs → dao+bmo

Updated

7 months ago
Keywords: addon-compat
(Assignee)

Comment 75

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

Updated

7 months ago
Summary: Provide ways of opening new tabs next to the current tab → Let accel-click and middle-click on the new tab button open a new tab next to the current one

Comment 76

7 months ago
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

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/cd5beac45eac
Status: ASSIGNED → RESOLVED
Last Resolved: 7 months ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51

Updated

3 months ago
Blocks: 1325014

Updated

3 months ago
Blocks: 1327284

Updated

2 months ago
Blocks: 1331595
See Also: → bug 933532
You need to log in before you can comment on or make changes to this bug.