Treestyletab: Flat/wrong tree structure when restore tabs using TSM

[AnatISR]

This problem start on 9 March 2019 after a firefox automatic update.
Firefox 65.0.2 64 bit updated on 9/3/2019
Tree Style Tab 2.8.3 from 7/3/2019 and 2.8.4 from 11/3/2019 by @piroor
Tab Session Manager 4.5.2 from 16/2/2019 by @sienori

I must say that I love TST and can't do without.
I used to use the old session manager. but since it gone, I use TSM that can read even old json files.

the problem started after last firefox update on 9/3/2019.
the firefox "forgot" all the tabs. so I just open TSM and open the last session.
I got wrong trees structure or flat.

I decided to try on small new made trees. make them. save in TSM and open to a new win.
example (I put letter as level):
1 - ABBC became flat
2 - ABABAB became flat
3 - ABBCAB became AAAAAB
4 - ABBCAB became AAABAB (dont remember or know the difference from 3...)
5 - AABBCBC became AAAABAB

today I made few more checks:
I tried to uninstall and install TSM. did not help.

I figure that the option to restore last open tabs was disabled since the firefox update.
I checked to see if closing and reopen firefox restore the tree structure. It restore correctly.

I uninstall and install the TST. maybe it became then 2.8.4 and I did not notice.
I pay attantion that it looks like it show only trees from level 3, and also that not all the time.
I could not discover more then this rule.

I choose to refresh firefox (I only read few minutes ago about the option to run a clean profile without realy refresh permanently).
I instal TST (no change in parameters)
I install TSM (TST must be on. I use to put 500 in the ms instead of 150 but it did not help. even 2000.)
make few trees. save in TSM and open to new win.
It gives flat trees.
I tried to play with th TSM parameters:
when lazy unchecked, it give wiered result, and consistant in it. with and without discard.
first win: ABCBABB restored correct structure.
the second is a mess
ABBCBAABBCDEEEAAABCDCCCAAA became
ABBCABBBBBBBBBBBABCDCCCCCCA
also, the last A in the second is the second A in the first. realy a mess.....

when puting lazy and discard back:
first win: ABCBABB became ABCBAAA
second win before: ABBCBABBCDEEEAAABCDCCCAAA
seond win after: AAAAAAAAAAAAAAAAABCDCCCAAA

I tried your automatic tool and it says: done.
I can run test as you like and send logs if it helps. just give me instructions.

so, I dont know who make the mess out of the 3 (FF,TST,TSM)
but I love your addon and I just need it to work with a session manager or any other restorer.
I hope I gave any detail in order for you to reproduce it and find where the bug came from.
waiting for good news.

[piroor]

On my environment, tabs in a window opened by TSM looks to have no information to construct tree. TST constructs tree of tabs implicitly based on tab's openerTabId, but those "restored" tabs don't have the property (TSM looks not giving the property when tabs are opened). Moreover, TSM currently don't call any TST-specific API to construct tree explicitly.

(I put letter as level)

Sadly I couldn't understand what is the expected and actual tree from those descriptions. List format looks more helpful to figure tree structure, like:

 * A
   * B
     * C
   * D
     * E

[sienori]

To restore a tree structure with TSM, you need to enable the Supports Tree Style Tab option.
Enabling this option gives OpenerTabId to the restored tab.

[piroor]

@sienori Thanks, I forgot the option.

@AnatISR I've tried with some situations, and TST 2.8.5 (I've released now) looks working as expected with TSM for me. Could you try updating?

[AnatISR]

@piroor
I just used Tree Style Tab 2.8.6 from 17/3/2019

when I write "before" - it means the save tree and the expected tree
when I write "after" - it means what I realy got, insted...

I don't write trees like you do, caues it takes too many rows and hard to write.
every example is a window includs tabs as few trees.
the letter means the level of decendent. it has all the information in order to draw a tree (I think...).
I put now spaces between trees, so it will be more readable.

I saved the window with trees: A ABBBBBB A ABC A ABB AAA
after save and open from TSM I got: A AAAAAAA A ABC A ABBAAA
meaning: all the first tree became flat, the other 2 trees restored correct. all tabs restores, no one missing.

[AnatISR]

@piroor
you right to use:

• A
  
  
  
  • B
    
    
    
    
    
    • C
    
    
    
  
  
  • D
    
    
    
    
    
    • E
    
    
    
  
  

when order can be change.
but in my cases, the order is correct, but there are many tabs, so I write it: ABCBC
sory if it confused u. but I was afraid to not draw correctly the level of insertion.

if you have ready made examles trees for test, you can send me.
or better, if you have something automatic. or sets of trees.

[AnatISR]

Another strange thing I am not sure is ok,
for some of the tabs, it does not put the original icon of the tab (the site icon),
but instead there is a strange circle with rectangle in it. supposly for unloaded ones. but not sure.
when windows recover, after close and open firefox, it shows the icins correctly.
also, all icons shown correctly before that issue. the strange icon and the wrong levels, start together.

for example:
I made a tree and saved (expected):

• A
  
  
  
  • B
    
    
    
    
    
    • C
    
    
    
  
  
  • D
  
  
  • E
    
    the result after open from TSM
  
  
• A
  
  
  
  • B (circle icon)
    
    
    
    
    
    • C (circle icon)
    
    
    
  
  
  • D
    
    
    
    
    
    • E (circle icon)
    
    
    
  
  

(D and E moved level down.)

[piroor]

I don't write trees like you do, caues it takes too many rows and hard to write.

Please remind: saving time for you means taking time for me. I asked you to describe with figures because your "encoded" description is hard for me to "decode" with my poor English understanding.

I saved the window with trees: A ABBBBBB A ABC A ABB AAA

Does this mean:

• A
• A
  
  
  
  • B
  
  
  • B
  
  
  • B
  
  
  • B
  
  
  • B
  
  
  • B
  
  
• A
• A
  
  
  
  • B
    
    
    
    
    
    • C
    
    
    
  
  
• A
• A
  
  
  
  • B
  
  
  • B
  
  
• A
• A
• A

? Am I successfully "decode"d your description?

[AnatISR]

Yes
and the result after save in tsm and open from tsm is:

A
A
A  (instead of B)
A  (instead of B)
A  (instead of B)
A  (instead of B)
A  (instead of B)
A  (instead of B)
A
A
    B
        C
A
A
    B
    B
A
A
A

[AnatISR]

@piroor / @sienori
Any news ?
Any test tree you can write and I will check ?
Maybe something wrong in the firefox 65.0.2 version ?
Any swirches wrong ? or missing/stoped services ?
Am I the only one have this problem or anybody else have it ?
what should I do ?
please instruct me.
.
.
.
I realize maybe there is less conflict with TSM.
I realize once, after my laptop crash, that the firefox windows not realy recover correct all the time.

to test it,
I opened a new window and made few trees. then close the window with the X.
then go to "library sign" - >"history" -> "last closed windows" -> and choose the last window.
I expect it to be the same like the one I just closed, but it is not always...
I put here some that got back and some that are not...
I rerun the examples to be sure it give the same result and not only once. to check repeatability.

I used Tree Style Tab 2.8.7
example1:
the closed win - expected

• A
• B
  
  
  
  • C
  
  
  • D
  
  
• E
  
  
  
  • F
    
    instead I got:
  
  
• A
• B
  
  
  
  • C
    
    
    
    
    
    • D
    
    
    
  
  
• E
• F

example2:
the closed win - expected - also what I got

• A
• B
  
  
  
  • C
    
    
    
    
    
    • D
    
    
    
  
  
• E
  
  
  
  • F
  
  
• G

example3:
the closed win - expected - also what I got

• A
• B
  
  
  
  • C
    
    
    
    
    
    • D
    
    
    
  
  
• E
  
  
  
  • F
  
  
• G
  
  
  
  • H
  
  

example 4
the closed win - expected

• A
  
  
  
  • B
    
    
    
    
    
    • C
    
    
    
  
  
• D
  
  
  
  • E
    
    instead I got:
  
  
• A
• B
• C
• D
• E

I hope now, that the TSM is out of the equasion, it will be easier to find what is wrong in the new firefox version, and maybe adjust TST.
(I also learened how to easily write the trees here with the markdown....)
waiting for your news, or if you need more test or examples.
Thanks

[AnatISR]

I opened a new issue 2201, not related to TSM.
I just check example1 of issue 2201, and it also happened when save and open in TSM.
After 2201 will be solved, I will check tje current issue and close it if it also corrected.

[AnatISR]

I just now checked again with firefox 66.0.1
It give different results. sometimes as expected and sometimes missing nodes and movement in levels.
I wrote them down (in notepad), but I don't want to add more and more examples.
I test the save and open TSM but also close window and open from history.

One wierd test was:
I open a closed window, it apear flat.
I closed it and open again from history, it became as the expected tree it was before.
It was a very simple tree. ABCD(level1) then E inside(level2) , then FGHI (in level 1).
The problem is that it behave different every time.
I also tried in firefox 66.0.2
It behave almost the same but sometimes other results.

I give up.
Please check few times the close - reopen history and the tsm save open.
just to tell me if it is only in my laptop or you enable to reproduced it.

@piroor @sienori
thank you

[piroor]

FYI: there are two different cases about window restoration.

• When a window is restored by Firefox's built-in session feature (Ctrl-Shift-N or the "Recently Closed Windows" menu), TST tries to restore tree structure of tabs based on information stored by TST itself. (#2201)
• When a window is restored by TSM, TST doesn't "restore" tree structure, instead TST tries to construct new tree based on openerTabId information of each tab opened by TSM. (this issue)

On my environment, TST latest development build looks working for both cases as expected. But I just tried with 10 or less tabs, so these changes possibly ineffective and the problem still there...

[irvinm]

@AnatISR any update from your end? If still an issue, please provide an update or if resolved, please close this issue. Thanks.

[irvinm]

@AnatISR any updates?

[irvinm]

@piroor I think we can close and mark "expired".

[AnatISR]

sorry,
I had problem in my mail since April.
I just now saw all the massages.
again, sorry.
In the mean time I had different trees opened each time but I did not record it and ignore.
Usually I worked on many tabs.
now I will make a new trial for issue #2201 and issue #2187
and will write here the results.
Anat

[irvinm]

@AnatISR any updates?

[irvinm]

@piroor I think we can close this. No updates from OP since July 18.

[gbutler69]

I've started having this issue with the latest TST. Firefox version 79.0 (64-bit). TST Version 3.6.17.

When I started FF today, all my (hundred or more) tabs opened in a flat structure instead of the trees they've been in for weeks.

Any way to get the structure back without rebuilding it manually?

[piroor]

@gbutler69 If you couldn't get expected tree structure after reopening the sidebar, sadly the old tree structure was lost forever.

TST's tree structure information is saved as a metadata bundled to Firefox's session information for each tab. If TST cannot read such a metadata for tabs, it looks to mean that those tabs are treated as different from the original one, otherwise the relation of tabs and their metadata were lost. Such a situation can happen when tabs were lost and something addon reopens lost tabs with no metadata.

[donw146]

I lose tree structure info several times a month. However, I store all my sessions as single window sessions. If the problem happens, most of the time closing the window and reopening the session fixes the problem.

While I haven’t attempted to reproduce the behavior, it appears that starting to use the browser window while the tabs are still opening is likely to mess up the tree structure.

Hope this helps.

Regards,
Don Walker

From: piroor [e-mail]
Sent: Thursday, August 6, 2020 13:03
To: piroor/treestyletab [e-mail]
Cc: donw146 [e-mail]; Manual [e-mail]
Subject: Re: [piroor/treestyletab] Flat/wrong tree structure when restore tabs using TSM (#2187)

@gbutler69https://github.com/gbutler69 If you couldn't get expected tree structure after reopening the sidebar, sadly the old tree structure was lost forever.

TST's tree structure information is saved as a metadata bundled to Firefox's session information for each tab. If TST cannot read such a metadata for tabs, it looks to mean that those tabs are treated as different from the original one, otherwise the relation of tabs and their metadata were lost. Such a situation can happen when tabs were lost and something addon reopens lost tabs with no metadata.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/piroor/treestyletab/issues/2187#issuecomment-670054788, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB7JG5OQIINB4WZII6CON5DR7LO3XANCNFSM4G5QKNAQ.

[piroor]

By the way, now TST has ability to save tree structure to bookmarks via the operation: right-click on a tab, "Select All", and "Tree of Tabs" => "Bookmark Selected Trees". It lets you to take a snapshot of the tree as bookmarks in a folder. It is not a good alternative for backup sessions for crashes, but it can be useful on some situations.