right-click to open a page in a new tab should open the tab to the right of the active tab, not to the right of the tabstrip

[bbondy]

No description provided.

[psimyn]

I have made a branch with this. The existing behaviour for tab ancestors is a bit confusing user-wise though. It will open tabs to the right of tabs opened from the current tab. Useful for opening mutliple links in a row though

[bbondy]

The existing behaviour for tab ancestors is a bit confusing user-wise though.

Not sure I understand what you mean, we have the right behaviour when Command+click on links just not for the context menu.

It will open tabs to the right of tabs opened from the current tab.

Do you mean you think that is confusing? I think that is expected. I think Chrome works the same way.

[psimyn]

Oh yeah, didn't even think of that. I recall a browser that did ancestors, but reset when you switched away. Didn't think of chrome because new tab with keyboard always open far right

[psimyn]

Given that, the branch should work as expected. @bbondy do you think it's ok to check the setting in the Store, rather than updating add calls to the newFrame action? It doesn't override the value if it exists.

Also, missing the "open left of current tab" option in design spec - @bradleyrichter is "left of current tab" a desired option or it was there for symmetry?

[bbondy]

You can call getSetting from within stores ya, it no longer requires you to pass in all of the settings.

[bradleyrichter]

@psimyn Skip the "left" position for now. I'll remove it from the spec and wait for user requests.

• Brad

[psimyn]

@bbondy I'm still not convinced by the ancestor relationship remaining even after you leave the tab. This is the behaviour in the branch currently (and opening links in background tabs does the same thing):

The confusing part is after you switch to a different tab, then later come back to the first tab and "to the right" is to the right of all it's children.

Not sure of a good solution though, except maybe storing tab children and clearing them on switch.

[bradleyrichter]

@psimyn It would seem that the safest route to tab happiness is to reset the children on tab switch. Are there bad side effects? As you said above, opening a barrage of tabs-behind an active page is a use case for "right of child" but otherwise, opening to the immediate right should satisfy most of the time. (and pref to open at the end instead - as long as we can show you the tab.)

[bradleyrichter]

warming up this one...did we improve on this @bbondy ?

[psimyn]

@bradleyrichter I'll rebase this and try the reset children approach over the weekend. Can't think of and bad effects off the top of my head

[psimyn]

@bradleyrichter I've updated it, and made change to reset the children when switching tabs.

Should this only apply to new tabs opened from context menu / middle click? Currently this also affects clicking the + button or Ctrl T as well. Still thinking about what the preferred behaviour should be without it spiralling into dozens of config options

Needs a bit of implementation cleanup then I'll create PR

[bradleyrichter]

@psimyn The "+" button for new tab should probably always create a new tab at the end since it will be seen immediately to the left of the + button. Command + T could be assigned in settings but breaking the UI consistancy is questionable. So let's apply your change to context-menu opened tabs for now and we can test the other new tab instances with a few different chrome extensions.

Thanks for figuring this out!