Treestyletab: Errant tab indentation

[davidmbesonen]

[Windows 7 SP1, Firefox 68.3.0esr, TST v3.3.6 (upgraded today to v3.5.3)]

Intermittently, when restarting Firefox (with "Restore previous session" enabled) with around 2000 open tabs, after Firefox reloads a window, sometimes TST tab indentation is wrong. This screen-shot is a typical example of the phenomenon.

Has anyone else observed this bug?

I'm primarily reporting this for the record. I experienced this bug again today, so I updated to the latest version of TST in the hope that a more recent version might already contain a fix.

I typically see this bug at least a couple times a week. So let's leave this issue open and I will report back in a week as to whether or not v3.5.3 solved the problem.

[davidmbesonen]

[Windows 7 SP1 64-bit, Firefox 68.3.0esr, TST 3.5.3, 2000+ tabs]

Errant tab indentation also occurs when Firefox recovers from a crash (not a surprise given that recovery from a crash is similar to restoring tabs after previously exiting).

Firefox 68 (TST v3.5.3) just crashed and one of the restored windows had tabs with errant indentation, thus this report.

Here is a section of a screen-shot of the recovered window with errant tab indentation:

Now, for perhaps the more interesting details (this is somewhat speculative because I have not attempted to repeatedly reproduce these phenomena, although I have seen this occur multiple times randomly).

After Firefox restarts with the errant tab indentation, if I "Bookmark this Tree...", the saved tabs do include the errant tab indentation.

However, if I drag the top-most tab (with child tabs that have errant indentation) to another tab to become a child tab, all of the child tabs that previously had errant indentation "self-correct". And if I then "Bookmark this Tree..." again, this time the saved tabs have the correct tab indentation. The next section of a screen-shot is of the same set of tabs (above screen-shot) after the top-most parent was moved to become the child of a different top-most tab:

Pure speculation, it would appear that two different tab indentation values are being stored. The visual indentation level and the original indentation level. Otherwise, "Bookmark this Tree..." would save the same indentation levels both before and after the visual indentation levels are corrected.

This all secondary to the real question, why is this happening?

[piroor]

TST stores tree information of tabs like as:

• A parent tab can have zero or more children, it is an ordered list.
• A child tab can have zero or one parent.

Nested structure is expressed with chains of these simple information. So, a child tab can appear above its parent tab - it is totally wrong but valid on this data model. When a tree is moved, TST rearranges tabs in the tree based on the tree structure. This is the reason why a broken tree become fixed by drag and drop.

I wrote some codes to keep the order of tabs matching to the internal tree structure, but it is not perfect. So we can see tree of tabs with wrong order on some cases. If you can find out the condition to reproduce broken order of tree with 100% probability, it will help my debugging a lot. Thousands of tabs looks hard for me to try, sorry...

[davidmbesonen]

In response to the "help wanted" tag that was added to this issue, what type of help is needed?
That was written before I saw piroor's reply to my second comment (apparently I failed to refresh this issue window (different than the TST issue list window)).

piroor wrote:

Thousands of tabs looks hard for me to try, sorry...

No need to apologize, you've clearly put a lot of effort into TST already.

This is obviously a naive question; instead of trying to prevent tab indentation from becoming visually errant, might it be possible to verify and correct visual tab indentation by comparing the current indentation levels to those previously stored in the "tree structure"? Basically forcing what happens when a tree is moved except in situ either on-demand (eg. a "fix indentation" command) and/or automatically in a preventative manner whenever a windows is loaded with saved tabs.

Hypothetically, if there are many circumstances that produce errant tab indentation, this approach might be a blanket solution.

[davidmbesonen]

I don't know if this problem is related to the total number of tabs, I just included the information that I often have 2000+ tabs open in case it was relevant.

I have heard that there are other folks that successfully use TST with 1000+ tabs. If anyone reading this is in that category, I would be grateful if you would mention whether or not you've ever seen this errant tab indentation issue.

[irvinm]

I've maxed out at around 1200 tabs and usually run between 500-1000 most of the time and my indentation is perfect. There might have been some problems a while ago (I'd say more than a year ago) but now it is really stable for me.

[piroor]

@davidmbesonen Hmm, is there any other addon which can rearrange tabs while TST restores the tree structure?

[davidmbesonen]

@davidmbesonen Hmm, is there any other addon which can rearrange tabs while TST restores the tree structure?

That sounds impossible. Perhaps I'm misunderstanding you?

[davidmbesonen]

I think I have a more constrained example of TST producing errant tab indentation. Before I post the details @piroor, it would be helpful to know if is possible to locate an install timestamp for a currently installed add-on.

Explanation: I was switching between TST v3.5.3, v3.4.10, and v3.3.6 in an attempt to isolate a repeatable errant tab indentation example. And I would like to know when I installed the currently installed version of TST. I failed to record this piece of information (which will confirm the details of my finding) as I was documenting this example and I would rather not perform the test again just to obtain this singular piece of information if it was logged somewhere by Firefox.

[Rhialto]

Let me start with saying that I find TreeStyleTab an absolutely unmissable extension. I have far too many tabs open to handle them in a plain linear fashion.
I also sometimes see problems with the indentation. I have the impression that as soon as you get some problems with the indentation, you'll get more.
Here is an example that I just could reproduce at will:

• from any tab (the tab for this web page, actually), open a new tab with Control-T. That tab nicely opens an empty child window, properly indented.
• Type an URL (google, in this case) in the url bar.
• Now the tab representation shifts to the left.

After this, if I drag the "Issues - piroor/treestyletab" tab a bit (I tried dropping it on its parent), the errant Google tab gets moved all the way to the bottom. This is correct in the sense that the tab is independent and shown in the right place. But of course, it should have remained a child of its original parent.
This is with version 3.5.3 (2020.4.28) and Firefox (Nightly - built with pkgsrc for NetBSD) 74.0.

[irvinm]

Not sure I have anything to directly contribute to this issue, but just wonder if you guys have tried disabling the cache for TST to see if that improves your indentation issues over time. Just a suggestion to try. I've been running without the cache for a long time and don't even notice the performance change.

[Rhialto]

Yes, turning off the cache was the first thing I tried. It did not seem to help me.

[piroor]

@Rhialto From the screenshot a new tab looks to be configured to open next to the current tab, not the end of tabs. I've tried with some conditions but I couldn't reproduce that.

The initial state:

• Parent Tab
  
  
  
  • Child Tab 1 (active)
  
  
  • Child Tab 2
  
  

Case 1:

1. Go to about:config and set browser.tabs.insertAfterCurrent to true.
2. Activate the child tab 1.
3. Ctrl-T to open a new tab.
4. Input example.com into the location bar and hit the Enter key.

Case 2:

1. Go to about:config and set browser.tabs.insertAfterCurrent to true.
2. Go to the options page of Firefox and set Home => New tabs => "Blank Page".
3. Activate the child tab 1.
4. Ctrl-T to open a new tab.
5. Input example.com into the location bar and hit the Enter key.

Any other conditions to reproduce the problem? I'll be happy if you describe complete steps to reproduce with a clean profile because I'm not familiar to configurations on your case.

[Rhialto]

Thanks for investigating. I can imagine that reproducing my example is difficult if it depends in a subtle way on all my other tabs. I will try to experiment with a clean profile. If I find anything that I can reproduce, I will report.

Meanwhile, here are the settings that I use. That "export" function is very convenient!

{
  "animation": false,
  "applyThemeColorToIcon": true,
  "autoAttachOnNewTabCommand": 1,
  "closeParentBehaviorMode": 1,
  "collapseExpandSubtreeByDblClick": true,
  "colorScheme": "system-color",
  "configsVersion": 9,
  "context_closeDescendants": true,
  "context_closeOthers": true,
  "context_collapseTree": true,
  "context_expandTree": true,
  "context_reloadDescendants": true,
  "fixupTreeOnTabVisibilityChanged": true,
  "guessNewOrphanTabAsOpenedByNewTabCommandUrl": "about:blank",
  "inheritContextualIdentityToNewChildTab": true,
  "labelOverflowStyle": "crop",
  "lastConfirmedToCloseTabs": 1587829618137,
  "lastDraggedTabs": {
    "tabIds": [
      86
    ],
    "urlsDigest": "1b1d68d85e14b395143674e569bf1d4b02e1a40f"
  },
  "migratedBookmarkUrls": [
    "moz-extension://e72eca68-6a7c-49e9-bc25-a22ddde77f9b/resources/group-tab.html",
    "moz-extension://e72eca68-6a7c-49e9-bc25-a22ddde77f9b/options/options.html",
    "moz-extension://e72eca68-6a7c-49e9-bc25-a22ddde77f9b/resources/startup.html",
    "moz-extension://e72eca68-6a7c-49e9-bc25-a22ddde77f9b/tests/runner.html"
  ],
  "notifiedFeaturesVersion": 4,
  "optionsExpandedGroups": [
    "group-allConfigs"
  ],
  "optionsExpandedSections": [
    "section-shortcuts",
    "section-debug",
    "section-drag",
    "section-advanced",
    "section-treeBehavior",
    "section-addons",
    "section-appearance",
    "section-contextMenu",
    "section-newTab"
  ],
  "showAutoGroupOptionHint": false,
  "showExpertOptions": true,
  "style": "plain",
  "tabDragBehaviorShift": 4,
  "treeDoubleClickBehavior": 1,
  "useCachedTree": false
}

In the firefox main prefrences, my "new tabs" are set to "blank page". I think earlier that was explicitly shown as "about:blank".

[piroor]

@Rhialto Thank you for more info! I've imported the JSON but still couldn't reproduce the problem. Hmm...

[irvinm]

@piroor I think this should be closed unless we can get a better way to reproduce this.

[piroor]

Today 've tryied to reproduce this with very large number tabs, and I've possibly reproduce this. Now I have 1080 tabs and those tabs are collapsed, and when I expand restored collapsed trees, some sub level tabs are shown with wrong indent.

• When the problem happens, the tab data of a misindented tab in the presentation layer (sidebar page), it has a level data different from the tab data in the background page.
• After close and reopen the sidebar the problem disappears for me. This is because sidebar contents are reinitialized from tab data exported from the background page.

I need to do more research why such a missynchronization happens... Anyway it looks to be triggered with slow startup from very very large number of tabs. I couldn't see it on my daily use with about 250 tabs.

[piroor]

TST calculates the indent level at the background page. When the indent level of a tab is changed, the background page sends notification message for every level changes. On the startup tree restoration, such a change is very frequently done for each tab multiple times, like 2 => 3 => 4. I assume that such messages looks to be processed in wrong order like 3 => 4 => 2 at the presentation side, when the startup process is slow due to too many tabs.

[piroor]

OK, I got why the problem happens.
https://github.com/piroor/treestyletab/blob/10d8c545fa79fbbba7fc88acc816e49791102349/webextensions/sidebar/indent.js#L222-L229
On this section, changed indent levels are received in expected order like 2 => 3 => 4. However, sometimes the statement await Tab.waitUntilTracked(message.tabId, { element: true }); for a later message is resolved before the one for an earlier message.
As the result finally messages are applied in wrong order like 4 => 3 => 2.

[piroor]

Handling of asynchronously notified messages from the background script on the sidebar page are now stabilized with recent changes. It should solve all this kind bugs not only indentation but collapsed/expanded state also.

[irvinm]

@davidmbesonen can you try again with the latest build and close this item if resolved?

[irvinm]

@davidmbesonen, a friendly reminder ...

[irvinm]

@piroor maybe we should close this. No contact from the original poster since May.

@Rhialto how are things for you?