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

[TSTisAwesome]

After I upgraded Firefox to 60.0.1 today, 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): Fedora 27, KDE
• Version of Firefox: 60.0.1
• Version (or revision) of Tree Style Tab: 2.4.21

Workaround

In the custom keyboard shortcuts TST settings I set CTRL+5 to "Open a new tab: Child tab" and it works as expected. Still would very much like to be able to use CTRL+T.

[piroor]

I cannot reproduce this problem on my environment: TST latest development build, Firefox 60.0.1 on Windows 10 and Ubuntu 16.04LTS. Any other required condition to reproduce, like other addons?

[TSTisAwesome]

Only Cookie AutoDelete 2.2.0 and uBlock Origin 1.16.8. I can't think of anything else that might be causing the problem. It happened right after I updated Firefox.

Sometimes when I open Firefox some of the level 2 trees become root (level 1) trees and I have to manually drag and drop them onto another tab (the folder tabs) to make them level 2. I don't know if that's relevant. It has happened before Firefox 60.0.1.

Is there a way to export my TST settings? Will that help?

P.S. Just want to thank you for the amazing add-on. I can't imagine ever going back to the default tab row.

[piroor]

Hmm, after retrying I've realized that this problem sometimes happens and sometimes doesn't.

On some cases, TST tries to control position of newly opened tabs by some flags like "the tab next opened should become an independent tab". So I think that this problem can happen if TST failed to clear the flag. Thus, we should pay attention about what we did before opening new tab.

[TSTisAwesome]

I tried various patterns of opening, closing and moving tabs, but CTRL+T always opens the new tab as an independent tab at the bottom of the list.

Interestingly, even with CTRL+5 (my workaround) (or with CTRL+T in previous Firefox versions, or with the new tab button now) the new tab appears for less than a second as an independent tab at the bottom of the list and then it moves to the right position (child of current tab).

This doesn't happen when I open a new tab my middle clicking a link, though. Then it immediately appears below the current tab, but it starts with 0 indentation and after less than a second it moves to the right (where it should be).

I don't know if those things are related. I'm not a developer, so I can't play around with the code and test it.

[piroor]

background/handlers.js:

  if (!opener) {
    if (!aInfo.maybeOrphan) {
      if (isNewTabCommandTab(aTab)) {
        log('behave as a tab opened by new tab command');
        handleNewTabFromActiveTab(aTab, {
          activeTab,
          autoAttachBehavior:        configs.autoAttachOnNewTabCommand,
          inheritContextualIdentity: configs.inheritContextualIdentityToNewChildTab
        });
        return true;
      }

From these codes, "new tab is not handled as a new tab opened by Ctrl-T" cases may be caused only by three reasons:

1. When the tab has an "opener" information. (But this never happen for Ctrl-T tabs.)
2. When the maybeOrphan parameter is unexpectedly true.
3. When the tab is not opened with about:newtab. (But this never happen for Ctrl-T tabs, except browser.newtab.preload=false case.)

If you don't change browser.newtab.preload via about:config, only the second condition can be the reason triggering the problem on your environment.

---

maybeOrphan can become true when one or more tabs are opened in a window by TST itself. Cases the function is called are:

1. Session information is migrated from legacy version of TST.
2. The "new tab" button in the sidebar is clicked.
3. Bookmarks or URI strings are dropped into the sidebar.
4. Group tab is opened:
   
   
   
   • for child tabs from pinned parent tab.
   
   
   • for new tabs opened in a time.
   
   
   • by the "group selected tabs" command (called from Multiple Tab Handler)
   
   
5. A new tab is reopened in different container.
6. Keyboard shortcuts for "open new tab" commands.

These operations increments the counter for "the number of to-be-opened independent tabs", and decrements it when actual newly opened tabs are tracked. In other words, if TST fails to decrement the counter by something unexpected errors, the counter remain 1 or more and new tabs opened by Ctrl-T will be treated as independent tabs unexpectedly.

---

So, most important point is: what causes misdecrementing of the counter.

[piroor]

One additional note:

When the tab is not opened with about:newtab. (But this never happen for Ctrl-T tabs, except browser.newtab.preload=false case.)

Even if you use Firefox with browser.newtab.preload=true (it is the default configuration of Firefox), TST can misdetect a new tab when it is not completely preloaded. For example: too heavy contents requiring long loading.

[piroor]

By the commit 6cd2fad, TST now decrements the counter immediately and it won't be remain 1 or more unexpectedly. So I think that the problem described at https://github.com/piroor/treestyletab/issues/1909#issuecomment-392645156 never happen. Could you try the latest development build?
https://piro.sakura.ne.jp/xul/xpi/nightly/treestyletab-we.xpi
(note that you need to install this with disabled signature check.)

[TSTisAwesome]

Thank you for taking the time to review the problem. I installed the .xpi (2.4.21.6866) and set browser.newtab.preload=true (it was false). I even restarted Firefox. Sadly, the problem persists. CTRL+T opens an independent tab at the bottom, while the "new tab" button and CTRL+5 work. :(

[piroor]

Hmm, could you collect debug log when you hit Ctrl-T? Instructions: https://github.com/piroor/treestyletab/wiki/How-to-inspect-tree-of-tabs#how-to-collect-debug-logs-of-tst

[TSTisAwesome]

I tried that (and I tried the browser console before I saw your comment). I get the same errors in both consoles:

Error: Invalid tab ID: 201 ext-browser.js
Sending message that cannot be cloned. Are you trying to send an XPCOM object? ExtensionUtils.jsm:533:50

I get the "Invalid tab ID" error when I close (not open) a tab that's at the very bottom of the tab list, regardless if I opened it with CTRL+T or by dragging a bookmark to the bottom or by using the "new tab" button. But the tab has to be at the very bottom. If I have tabs like "a, a1, a2, a21" and I close "a21", then I'll get the error. Then if I close a2, I'll get the error (because a2 is the last one after a21 is closed). But if I instead closed a1 (when they were "a, a1, a2"), I won't get an error.

The "Invalid tab ID" always gives me 8 repeats every time. (the red number next to the error that I can't copy).

I get the "Sending message that cannot be cloned" error ONLY if I open a tab with the "new tab" button - not with CTRL+T or with CTRL+5.

I played around with this for a while. I couldn't find other errrors that weren't from sites I was visiting while testing.

[piroor]

Oops, to collect logs you need to do two things: 1) use remote debugger for TST from about:debugging and 2) activate "debug mode" of TST itself.

[TSTisAwesome]

Sorry, I activated debug mode now.
Here are the logs: https://pastebin.com/ypC9HaBN (I'm new to GitHub, I hope pastebin is OK.).
First I pressed CTRL+T, then I closed the tab with the middle mouse button.
Then I activated (line 66 in the log) "Print logs from tabs.onUpdated" and "Print logs from cached tree" and again pressed CTRL+T and closed the tab.
The 3 comments I put with "//" are about the number of repeats the console shows me (I can't copy the number, so I manually typed it in the logs).

EDIT: In the logs I see "12 more..." in some objects. I guess copying and pasting from the console isn't the best way to copy the log, since it doesn't show all the information. Should I make new logs?

[piroor]

Thanks a lot!

When I press CTRL+T:
(snip)
tst<BG>:     onTabOpening  #tab-3-214 Object { maybeOpenedWithPosition: false, maybeOrphan: false, restored: undefined, duplicated: false, duplicatedInternally: false, activeTab: <li#tab-3-212.tab.subtree-collapsed.contextual-identity-firefox-default.complete.active> }  common.js:21:60
tst<BG>:     behave as a tab opened with any URL  common.js:21:60

Hmm, sadly this log means that your case is: "When the tab is not opened with about:newtab." On your environment TST couldn't get the URL of a new tab opened by Ctrl-T - it is always about:blank, the default URL of any newly opened tab. As the result TST cannot detect what is the tab opened by Ctrl-T...

[piroor]

By the commit 9cc3038d now TST tries to detect a newly opened tab is opened by Ctrl-T or not with delay. I think this should work as expected on your environment also. Could you try that?: https://piro.sakura.ne.jp/xul/xpi/nightly/treestyletab-we.xpi

[TSTisAwesome]

Thanks again! I tried the new version and at first it didn't work. Then I searched in about:config for "newtab". I had set browser.newtabpage.enabled=false and browser.newtabpage.enhanced=false (because I just wanted a totally blank page with no ads, top sites, bookmarks, etc.). I set them both to true and now it works!!! Now the new tab page still appears blank to me, except for a small "settings" icon on the top right. Perfect!

I'll try the normal TST version now and will report if it still works. Sorry for wasting your time with this bug. I have a habit of aggressively changing about:config values. At least we now know what the problem was.

EDIT: I replaced the xpi with the official version I had backed up, updated it and it still works!

Thanks again for the time you took to help me. Your add-on is awesome and I wish more people knew about it.

[piroor]

Some addon provides ability to open any URI as the new tab by Ctrl-T. For example:

1. Install New Tab Override.
2. Go to the configuration page and set new tab page to "custom URL" and specify about:blank?newtab. The part ?newtab is required to treat it is not just a blank tab.

Then I successfully opened a completely blank page at my favorite position.

[TSTisAwesome]

Cool, thanks! Although now even though the two prefs are set to true, the new tab page is blank. So I don't really need New Tab Override. Although it could be useful to open something in the new tab page by default.

[Bumbadawg]

I confirm @TSTisAwesome solution: setting browser.newtabpage.enabled=true fixed this issue for me as well.

[yati-sagade]

For people still facing the issue, it was a simple config change for me: go to about:addons, and then to TST preferences, and under the "Behaviour for new tab actions" section, set the value of "Open new blank tab as" accordingly.

[piroor]

I close this because outdated.