New tab with CTRL+T opens after all other tabs (as an independent tab), despite TST settings (Firefox 73.0)

[Gaibhne]

I am almost certain that this is a regression of #1909 because I can just copy the error description from there verbatim:

CTRL+T doesn't open a new tab as a child of the current tab, but as an independent tab (the last tab in the tree). The "new tab" button works as expected, though.

When I close the tab with CTRL+W, though, it brings me back to the previously opened tab, not the last tab in the tree. Except when I open two tabs with CTRL+T and close them both with CTRL+W. Then it brings me back to the last tab in the tree, not the tab I opened the first of the two tabs from.

Expected result

CTRL+T opens a new tab as a child of the current tab.

Actual result

CTRL+T opens a new tab as an independent tab.

Environment

Platform (OS): Windows 10, latest non-Insider
Version of Firefox: 73.0, 64 bit
Version (or revision) of Tree Style Tab: 3.3.5

I have tried various permutations of new tab as blank, new tab as about:newtab and so on. The debug console only shows uncaught exception: undefined with no further details when I open a new tab.

[irvinm]

I am sure @piroor will look at this, but you could also consider using browser.tabs.insertAfterCurrent.
https://www.reddit.com/r/firefox/comments/81e9tn/new_pref_in_nightly_to_make_all_tabs_open_next_to/

[piroor]

Sadly this doesn't happen on my environment: TST development build on Firefox 73.0.1 on Windows 10. The option to control new tabs works as expected with the Ctrl-T shortcut also for me.

I think it may be affected from system (or network) performance and the number of total tabs opened on Firefox. We need to narrow down exact conditions to reproduce the problem.

[JeanMertz]

I'm seeing the exact same behaviour as described by @Gaibhne, including the behaviour of switching back when opening one tab and then closing it, vs opening two tabs and closing both.

This is on Firefox 73.0.1 on macOS 10.15.

I think it may be affected from system (or network) performance and the number of total tabs opened on Firefox. We need to narrow down exact conditions to reproduce the problem.

In my case, this is an 8-core machine doing nothing right now, with a 500Mbit connection, again doing mostly nothing. Also, I've got less than 10 tabs open.

I am sure @piroor will look at this, but you could also consider using browser.tabs.insertAfterCurrent.

This works somewhat, but not completely as expected right now.

If I have a root tab with one child, the root is active, I can see the following situations:

• 1x cmd+T, 1x cmd+W: new tab gone, focus on root
• 2x cmd+T, 2x cmd+W: new tabs gone, focus on child
• 3x cmd+T, 2x cmd+W: 2 new tabs gone, focus on child, root now has two children

[piroor]

@JeanMertz

* 1x cmd+T, 1x cmd+W: **new tab gone, focus on root**
* 2x cmd+T, 2x cmd+W: **new tabs gone, focus on child**
* 3x cmd+T, 2x cmd+W: **2 new tabs gone, focus on child, root now has two children**

They are by design, based on a simulated behavior of Firefox's browser.tabs.selectOwnerOnClose=true. "Back to the owner" behavior is not applied after you open any new tab or you give focus to different tab gets focused.

[Polisson]

Yes, this issue still persists on
Name Firefox
Version 77.0
Build ID 20200528194502
Update Channel release
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
OS Windows_NT 10.0

[piroor]

Hmm, I still cannot reproduce it on my environment. The screencast is very helpful for me to try same steps, but sadly new tabs are opened as a child of the active tab for me...

• Firefox 77.0.1
• Build ID: 20200602222727
• Update channel: release
• UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
• OS: Windows_NT 10.0

[piroor]

If you OK, could you collect a debug log? It possibly help my debugging. Steps to collect logs:

1. Configure TST to open new blank tab as a child of the active tab.
2. Activate TST's debug mode: TST Options => Development => Turn on "Debug mode".
3. Activate logs for "new tab" reaction. Under the "Detailed logging" section, please turn on only background/handle-new-tabs and background/api-tabs-listener.
4. Open a debugger for TST: about:debugging => This Firefox => Tree Style Tab => Inspect.
5. Choose the "Console" tab in the debugger.
6. Open a new browser window.
7. Back to the debugger's console and click the trashbox button to clear old logs.
8. Back to the new browser window opened at the step 6.
9. Hit Ctrl-T to open a new tab.
10. Back to the debugger's console and copy all output.

For example, here is a log on my success case:

tst<BG>: 01:40:05.552 background/api-tabs-listener:     tabs.onCreated:  #13(!tracked) common.js:400:13
tst<BG>: 01:40:05.554 background/api-tabs-listener:      onNewTabTracked(i#13(tracked)):  
Object { id: 13, index: 1, windowId: 91, highlighted: true, active: true, attention: false, pinned: false, status: "complete", hidden: false, discarded: false, … }
 
Object { window: {…}, positionedBySelf: false, mayBeReplacedWithContainer: false, duplicatedInternally: false, maybeOrphan: false, activeTab: {…} }
common.js:400:13
tst<BG>: 01:40:05.557 background/api-tabs-listener:     onNewTabTracked(#13(tracked)): start to create tab element common.js:400:13
tst<BG>: 01:40:05.571 background/api-tabs-listener:     tabs.onActivated:  
Object { id: 13, index: 1, windowId: 91, highlighted: true, active: true, attention: false, pinned: false, status: "complete", hidden: false, discarded: false, … }
common.js:400:13
tst<BG>: 01:40:05.599 background/handle-new-tabs:         Tabs.onCreating  #13(tracked) 
Object { positionedBySelf: false, mayBeReplacedWithContainer: false, maybeOrphan: false, restored: undefined, duplicated: false, duplicatedInternally: false, activeTab: {…}, fromExternal: false }
common.js:400:13
tst<BG>: 01:40:05.601 background/handle-new-tabs:         behave as a tab opened by new tab command common.js:400:13
tst<BG>: 01:40:05.606 background/handle-new-tabs:          handleNewTabFromActiveTab: activeTab =  #11(tracked) 
Object { activeTab: {…}, autoAttachBehavior: 1, dontMove: false, inheritContextualIdentity: false }
common.js:400:13
tst<BG>: 01:40:05.613 background/api-tabs-listener:         Tree modification is detected while waiting. Cached tree for action detection is updated:  
Object { target: {…}, active: {…}, tabs: (2) […], tabsById: {…} }
common.js:400:13
tst<BG>: 01:40:05.622 background/api-tabs-listener:     onNewTabTracked(#13(tracked)): moved =  false common.js:400:13
tst<BG>: 01:40:05.622 background/api-tabs-listener:     onNewTabTracked(#13(tracked)): uniqueId =  
Object { id: "tab-utopic-drake-1591288805581-302", originalId: null, originalTabId: null, duplicated: false }
common.js:400:13

[Polisson]

Apologize that it took so long. Review console log which I produced as You asked:

tst<BG>: 09:40:26.974 background/api-tabs-listener:      onNewTabTracked(i#351(tracked)):  
Object { id: 351, index: 1, windowId: 596, highlighted: true, active: true, attention: false, pinned: false, status: "complete", hidden: false, discarded: false, … }
 
Object { window: {…}, positionedBySelf: false, mayBeReplacedWithContainer: false, duplicatedInternally: false, maybeOrphan: false, activeTab: {…} }
common.js:401:13
tst<BG>: 09:40:26.976 background/api-tabs-listener:     onNewTabTracked(#351(tracked)): start to create tab element common.js:401:13
tst<BG>: 09:40:26.985 background/api-tabs-listener:     tabs.onActivated:  
Object { id: 351, index: 1, windowId: 596, highlighted: true, active: true, attention: false, pinned: false, status: "complete", hidden: false, discarded: false, … }
common.js:401:13
tst<BG>: 09:40:27.073 background/handle-new-tabs:         Tabs.onCreating  #351(tracked) 
Object { positionedBySelf: false, mayBeReplacedWithContainer: false, maybeOrphan: false, restored: undefined, duplicated: false, duplicatedInternally: false, activeTab: {…}, fromExternal: false }
common.js:401:13
tst<BG>: 09:40:27.073 background/handle-new-tabs:         behave as a tab opened by new tab command common.js:401:13
tst<BG>: 09:40:27.073 background/handle-new-tabs:          handleNewTabFromActiveTab: activeTab =  #350(tracked) 
Object { activeTab: {…}, autoAttachBehavior: 0, dontMove: false, inheritContextualIdentity: true }
common.js:401:13
tst<BG>: 09:40:27.075 background/api-tabs-listener:     onNewTabTracked(#351(tracked)): moved =  false common.js:401:13
tst<BG>: 09:40:27.075 background/api-tabs-listener:     onNewTabTracked(#351(tracked)): uniqueId =  
Object { id: "tab-edgy-unicorn-1592811626988-588", originalId: null, originalTabId: null, duplicated: false }
common.js:401:13
Security Error: Content at moz-extension://124d16e3-3a0a-4d0e-a9dd-ecb364ebd628/background/background.html may not load or link to about:newtab.

[piroor]

Thanks, I've seen there are two differences:

• Tree modification is detected while waiting. Cached tree for action detection is updated: is missing on your case.
• There is an extra line Security Error: Content at moz-extension://124d16e3-3a0a-4d0e-a9dd-ecb364ebd628/background/background.html may not load or link to about:newtab. on your case.

Currently it is unclear that these difference causes the problem or not...

[Githubwoman]

I've got same issue on one of my PC.
But setting in about:config "browser.tabs.insertAfterCurrent" to true seems to resolve that problem. At least if you want your new tab to just be a child of current tab and to go as first.

On my second PC that issue isn't occurring. I will check there if "browser.tabs.insertAfterCurrent" is set.

[yangkev]

I've noticed that when enabling "open new blank tab as child of the current tab", this behavior only works correctly with CTRL-T (CMD-T in my case on Mac) when about:preferences has "New Tab" set to "Firefox Home (default)".

When this preference is set to "blank page", or is overrode by an extension (like Momentum), despite setting "open a new blank tab as child of the current tab", hitting CTRL-T will instead open a new tab at the end of the TST tab list (the same, incorrect behavior I believe OP is seeing).

Firefox Version: 82.0.2
TST version: 3.5.34
OS: MacOS 10.15.7

[piroor]

@yangkev It looks a known issue described at the FAQ. The workaround may help you: https://github.com/piroor/treestyletab/blob/trunk/README.md#troubles-unexpected-behaviors

If you use New Tab Override to set a custom URL to the new tab page, you need to set the TST's option New Tabs Behavior => Basic control for New Blank Tab => Guess a newly opened tab as opened by "New Blank Tab" action, when it is opened with the URL to the internal URL of New Tab Override instead of the URL of finally loaded custom page. It is moz-extension://XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/html/newtab.html, the UUID part can be found at about:debugging#/runtime/this-firefox => Extensions => New Tab Override => Internal UUID.

[piroor]

@yangkev Oops, sorry you commented about Momentum. You can get the actual URL of the new tab page provided by an addon with the method: open a new tab and show the developer tool with the keyboard shortcut Ctrl-Shift-K, then type location.href in the console. You'll see the actual URL of the new tab page like moz-extension://XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/dashboard.html.