#1201 causes new tabs in Vimperator to always be opened as children of the current tab

[dadrc]

Short description

After installing the latest TST (0.19.2017031101), new tabs opened with Vimperator's :tabopen are always opened as children of the current tab. This happened once before and was fixed (see 5digits/dactyl#140). After reverting commit 6d0199b, the problem disappears, so I'm quite sure it's the culprit.

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. Install Vimperator.
4. Use :tabopen (or one of its bindings) to open a new tab.

Expected result

The new tab is opened as an independent tab.

Actual result

The new tab is opened as a child of the current tab.

Environment

• Platform (OS): Ubuntu 16.04
• Version of Firefox: 52.0+build2-0ubuntu0.16.04.1
• Version (or revision) of Tree Style Tab: 0.19.2017031101

[symmetryrtemmys]

I can confirm that this is also the case, using the same reproduction steps, with Pentadactyl 7307 on Windows 10 and TST 0.19.2017031101.

[reuschling]

I can confirm this also, Linux, NO vimperator since some days (auto-update). Only thing I have is TabMixPlus, maybe it causes to similar issues than vimperator? Didn't try without yet.

[tgy]

I can confirm this, last version of Arch Linux, Firefox 52.0

[reuschling]

...do you say now it is a feature, not a bug? Really, it is totally unnatural to me that, when I type ctrl+t or select 'open new tab' in the menu, the new tab opens as child tab from the current tab. When I quickly want to open three new tabs, now I get a small tree of subtabs?
It should be clear that when I type ctrl+t the new tab is intependent from the current tab. Further, you can configure the behaviour of the browser (at least in tabmixplus) where a new tab should occur: e.g. at the end of the tabs, as right neighbour of the current tab, etc. Now, treestyle overwrites these configs, and forces me to a behaviour that I don't want. This is really a killer for me, and I am looking forward that the old behaviour is back - otherwise I sadly have no chance to use this wonderful treestyle plugin I learned to love anymore :(

[tgy]

@reuschling I don't see why you think this is not considered a bug. This is also configurable with treestyletab. Just look at this screenshot:

This issue is still open and someone will definitely work on it!

[reuschling]

Maybe I have misunderstood your link to the other, closed issue. There it is written 'tab is opened as independent tab, but should be opened as a child of the current tab.' Because this issue is closed, I interpreted it that the new behaviour is made by intention. Sorry If I am wrong.

I know the treestyle configuration, but selecting there 'independent tab' makes no difference in behaviour, at least in my firefox

[tgy]

@reuschling this issue was about the tab not being opened as a child of the current tab when the user wants it to be a child of the current tab (using relatedToCurrent:true).
By fixing this issue, it looks like @piroor broke something: now all tabs opened (whatever your settings are) are opened as children of the currently selected tab, as if relatedToCurrent:true was always passed to the browser.addTab method.

[guaraqe]

Same issue here. Using :newtab in Pentadactyl makes a child tab.

[tgy]

@guaraqe I advise you to downgrade tree-style-tab to the previous version (0.18.2016111701) and disable automatic updates for tree-style-tab while this issue is not resolved.

[guaraqe]

Perfect, thank you!

[sumyungguy]

I did some investigating of this:

It's related to Vimperator (and other addons) using browser.loadOneTab. If the tab is set to open in the foreground, and the addon doesn't specify whether it's related to the current tab, then TST creates it as a child tab. This is different from browser.addTab, if it's not specified as related, then it opens independent. There's a work-around already in Vimperator git master, using browser.addTab, unfortunately it's not released yet.

I'm not sure how Piro intends it to work. It didn't work this way prior to commit 6d0199b, and it doesn't seem like that was the intention of the commit.

I think the way TST handles browser.loadOneTab at the moment is strange, because opening the tab in the foreground always forces it to be a child tab. This is true even when relatedToCurrent is set to false!

If background load is specified as false (load in foreground), by either:

gBrowser.loadOneTab("about:blank", null, null, null, false, false);
gBrowser.loadOneTab("about:blank", {inBackground: false});

or when background load is not specified and preference browser.tabs.loadinbackground is false, then, since commit 6d0199b, a child tab is always opened. This caused the problem with Vimperator, because by default the :tabopen command opens in the foreground. Doing set activate-=tabopen or map t :tabopen! works around the problem.

It should have been possible to solve the problem in the Vimperator code by specifying that the new tab is not related:
gBrowser.loadOneTab("about:blank", {inBackground: false, relatedToCurrent: false});
In this case an independent tab should open, but a child is still opened instead. This certainly seems to be a bug in TST.

On the other hand, If background load is specified as true, then either a child or an independent tab opens, depending on the setting of relatedToCurrent, as expected. If relatedToCurrent is not specified, then an independent tab opens, as I would expect.

[piroor]

TST 0.19.x is already obsolete, so I close this.