@piroor
The latest TST v3.0.7 (obtained from Git) has numerous critical errors rendering is essentially unusable, from the moment first opened, which I've summarized below, together with associated logged errors and debugging results.
I've also summarized here (and in my following comments/replies here) the most important points, debugging results and potential fixes from my most recent replies to related issue #2199, which should be easier to follow than that longer thread (though you can also find further details there if needed).

TabsUpdate.completeLoadingTabs(window.id); // failsafe
browser.runtime.sendMessage({
type: Constants.kCOMMAND_PING_TO_SIDEBAR,
windowId: window.id,
tabs: window.export(true) // send tabs together to optimizie further initialization tasks in the sidebar
});


Please find below results of debugging with latest version from Git, as taken from this reply to issue #2199. I've included this here for easier referencing (vs. that longer issue thread), and because it relates primarily to issues described in this bug report, which also goes beyond unclickable tabs / tab syncing issues.
You can see this reply to #2199 for the Complete Console Log, if you want to refer to that. However, I cover and describe the key relevant entries plus provide Console screenshots further below, which I believe are easier to read.




First error occurs like always during init() in background.js:
Error: Could not establish connection. Receiving end does not exist.
Followed by:
14:50:50.998 TypeError: can't access dead object
ExtensionUtils.jsm:158:9
14:50:50.998 TypeError: Argument 1 of PrecompiledScript.executeInGlobal is not an object.
2 ExtensionContent.jsm:490:25
Then syncTabsOrder() throws Error after 10 sync attempts, after just 7 minutes of use and 11 tabs opened -- and without even opening multiple tabs at same time (just one at a time) and without any session restore (just started Firefox with new empty tab homepage):
14:53:40.469 Error: fatal error: mismatched tabs in the window 1:
1
10
11
12
+ 2
4
5
6
7
8
9
sidebar-tabs
Followed 25 seconds later by the following with tab 13 added (when should instead be treated as missing tab # 2?)
14:54:05.493 Error: fatal error: mismatched tabs in the window 1:
1
10
11
12
13
+ 2
4
5
6
7
8
9
Then there are 10x of the "Tab.waitUntilTracked for 2 is timed out (in bg)false" errors, like the following (which occur with either Async or Timeout in call stack, but at several different source locations):
14:56:23.525 Error: "Tab.waitUntilTracked for 2 is timed out (in bg)false"
timeout moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:958
setTimeout handler*waitUntilTracked/< moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:951
waitUntilTracked moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:950
waitUntilTracked moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:1016
onUpdated moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/background/api-tabs-listener.js:204
api-tabs-listener.js:194:13
14:56:23.525 Error: "Tab.waitUntilTracked for 2 is timed out (in bg)false"
timeout moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:958
setTimeout handler*waitUntilTracked/< moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:951
waitUntilTracked moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:950
waitUntilTracked moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/Tab.js:1016
onUpdated moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/background/api-tabs-listener.js:204
EventListenerManager.js:65:23
14:56:23.528 FATAL ERROR: Failed to get unique id for a tab 2: Error: "Tab.waitUntilTracked for 2 is timed out (in bg)false"
Async* moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:90
_tryLoad moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:100
_load moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:49
Configs moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:21
<anonymous> moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/common.js:16
Tab.js:182:15
14:56:23.529 Fatal async error: Error: "Tab.waitUntilTracked for 2 is timed out (in bg)false"
Async* moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:90
_tryLoad moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:100
_load moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:49
Configs moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/extlib/Configs.js:21
<anonymous> moz-extension://d9f19977-38ac-4464-a14f-a0309441d127/common/common.js:16
Which all occur at same time down to the millisecond (Possibly duplicate logging or some kind of duplicate registered handlers issue,eg. competing/racing and causing the issues?).
That is followed by:
Error: fatal error: mismatched tabs in the window 1:
Then 4 more:
14:56:23.525 Error: "Tab.waitUntilTracked for 2 is timed out (in bg)false"
Then:
null has no properties 2 background.js:1
receiveCS moz-extension://75df900c-cfae-4ad9-9966-c0fad16d0d45/background.js:1
onconnect_listener moz-extension://75df900c-cfae-4ad9-9966-c0fad16d0d45/background.js:1
a moz-extension://75df900c-cfae-4ad9-9966-c0fad16d0d45/lpfulllib.js:1
apply self-hosted:4422
applySafeWithoutClone resource://gre/modules/ExtensionCommon.jsm:539
asyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:2251
After that, almost every single time I open a new tab (manually, one at a time, as I browse) via middle click, I end up with tabs which whenever I click on them end up activating the wrong tab (for almost all new tabs, but maybe 10% of them seem to be clickable without issue for some reason), with the following error after even tab is opened:
Error: fatal error: mismatched tabs in the window 1:
These errors with tab order diffs always indicate the same thing: That Tab # 2 is missing.
Currently it seems TST corrupt state so that all tabs opened after that don't work in TST, and never corrects index # 2.
The most recent error entry is 1 full hour later, and still shows "+2" in tab order diff for the "Error: fatal error: mismatched tabs in the window 1:" errors that get thrown after every tab I open.
One or more (often all 3) of the following are interspersed in the log after every few "mismatched tabs" errors:
Then one or both of the following sets of errors appears periodically nearly exactly 60 seconds after "mismatched tabs" errors (for maybe 25% of the times those errors occurred):
15:11:32.724
null has no properties 3 background.js:1
and/or the following two (which occur together):
15:12:04.124 TypeError: can't access dead object
ExtensionUtils.jsm:158:9
15:12:04.125 TypeError: Argument 1 of PrecompiledScript.executeInGlobal is not an object.
ExtensionContent.jsm:490:25
Finally this ends up with the following:
16:35:16.964
null has no properties 4 background.js:1
16:35:25.909 Error: An unexpected error occurred undefined
16:37:26.208
null has no properties 2 background.js:1
Which includes the "Error: An unexpected error occurred" @ undefined, as I'd mentioned in earlier reply seems found in most of the cases where this kind of corruption occurs (where even all new tabs created after that error end up unclickable too).
It seems like that ends up preventing syncTabOrder() from every running again (just endlessly deferring via reserveSyncTabOrder), possibly due to reasons outlined in my previous reply, because its waiting for internalOrder == trackedWindow.order (and if not, then defers the syncing via reserveSyncTabOrder() until reaches 10 deferrments them just throws an error).
However, as detailed in my question further below, I only ever see the trackedWindow.order cached order array copy being set by syncTabOrder() itself and only if/when internalOrder is already equal to trackedWindow.order, which might therefore never occur.
It seems like maybe you should just attempt to sync up instead of continually deferring via reserveSyncTabOrder(), hence why tab #2 never gets synced/fixed, it just remains an issue, and therefore prevents all attempts to sync any other tab orders (even for new unrelated tabs) from that point forward for that window during that session (and even for future sessions too, permanently, if ended up using session restore).
Isn't syncTabsOrder() just essentially comparing whether internalOrder == trackedWindow.order, (where internalOrder is set from TabsStore.windows.get(message.windowId).order) and, if so, then you set trackedWindow.order = (the new) internalOrder and, if not, then you deferring the syncTabsOrder() call until later (via reserveToSyncTabsOrder())?
And then if deferred enough times (since no limit on that, and each reserveToSyncTabsOrder() call just resets the 100msec wait timer) you end up throwing an error? Where, then, outside of syncTabsOrder() do you either set trackedWindow.order = internalOrder (so that the comparison done in syncTabsOrder will succeed) or do you otherwise actually perform that reordering, if not?
In addition to fixing underlying issues described (eg. for syncTabsOrder() seeming to never complete, never correcting) at least for the most critical and recent issues, I would also suggest that instead of throwing errors in syncTabsOrder() if/when tabs ever do get out-of-sync (as is likely to remain an issue to some degree), which appears to compound the issues and result in more errors, that you just auto-correct by auto-reinitializing TST.
Specifically, when syncing does actually fail in a way that can't be recovered (even once fix the underlying issue described here), then just reinit TST window entirely (the only way to fix once gets into this frequently corrupted state).
Though its preferable to just reinit or recreate the TST sidebar window for browser windows when encountering 10+ failed retries instead of throwing an error to cause further corruption (affecting even all new new tabs opened by user after that point), I would, at the very least, suggest increasing the increasing the threshold for throwing an error to be closer to 100 instead of 10, for retryCount.
I would especially suggest that (if don't just perform reinit instead as is preferable) considering how quickly many attempts can occur (eg. 30+ in 3 seconds) before 2,3,4,5 actually gets corrected, and considering you are retrying potentially every 100msec per reserveToSyncTabOrder()'s timeout use, and possibly more often than that depending on where else reserveToSyncTabsOrder() and syncTabsOrder() are getting called.
Also, I was wondering if it might be that reserveToSyncTabOrder() just keeps getting called to defer the actual syncing indefinitely, hence why 3 seconds and 30+ attempts later it still wasn't synced.
Also, I might suggest just logging an error instead of throwing it, because it seems that ever after "throw new Error(fatal error: mismatched number of tabs in the window ${windowId});" occurs, the corruption of tab sync order keeps getting worse, with errors onMouseDown (as seen in screenshot of Console) (as opposed to simply periodic syncTabsOrder() errors) for almost all tabs I open after that (in addition to most existing tabs), even for tabs I open hours after the error first was thrown.
After that initial error throw, I end up getting errors being thrown whenever even in onMouseDown to click on them, and resulting in other unrelated tabs being activated instead of them (sometimes even multiple tab jumps before landing on unrelated tab after a single click on a newly opened tab).
Is there any steps to reproduce? I'm not well about English, so reading large reports describing about "what is happened/happening" requires painfully much time and energy. Instead "how to reproduce" may be easier to read in general cases, especially cases there is screenshot or screencast. (Detailed report about what's happening will help investigation after I successfully reproduce the problem on my environment.) Otherwise, I need to put reports like this after the list of issues to be read by me...
@piroor
Please approve my pull request #2239, where I have implemented the following fixes and enhancements, covering many, but not all, of the issues detailed here:
However the issues that occur there making TST unusable, as well as many other critical issued I'd reported recently, are fixed if my Pull Request #2239.
Though you can ignore my previous replies here (and also in #2199) once my Pull Request #2239 is approved, as it fixes those issues.
However, there is still at least one major issue remaining (after I had fixed a half dozen of the most critical ones), for which I've provided Steps to Reproduce and related details below:

TabsUpdate.completeLoadingTabs(window.id); // failsafe
browser.runtime.sendMessage({
type: Constants.kCOMMAND_PING_TO_SIDEBAR,
windowId: window.id,
tabs: window.export(true) // send tabs together to optimizie further initialization tasks in the sidebar
});


These replies are possibly outdated, but I wrote them for records of development:
https://github.com/piroor/treestyletab/issues/2238#issue-435920487
- Tabs Displayed in Wrong Order
- First Tab Never Shown as Loaded
- Background init() error fails to send tabs initially
- All New Tabs are Tab Mismatch Become Unclickable Too Because syncTabsOrder() Always Fails to Run
- Should Reinit TST for Window after Multiple Failed Attempts (Not Leave All Existing + Even New Tabs Created Days Later to be Broken Too)
1, 4 and 5 should be fixed with the auto-rebuild logic imported from the PR #2239. ( https://github.com/piroor/treestyletab/pull/2239#issuecomment-486085560 )
2 should be fixed with 1e54567. ( https://github.com/piroor/treestyletab/pull/2239#issuecomment-486123741 )
3 looks to contain some misunderstandings.
SidebarConnection.init(); the master process accepts connections from sidebar processes. In other words, sidebar processes may try to send requests before the line is processed, if sidebar processes are loaded before the master process is completely initialized. This is an intentional operations for optimization, and the warning is sadly unavoidable on such cases.moz-extension://75df900c-cfae-4ad9-9966-c0fad16d0d45/background.js is not a part of TST on your environment.https://github.com/piroor/treestyletab/issues/2238#issuecomment-485581668
Question about syncTabsOrder() Deferred / Cached Tab Sync:
The function was originally introduced for "multiple tabs are opened and moved (ex. tabs opened from a bookmark folder)" cases. On such a situation, syncTabsOrder() may be called before all tabs are created in the sidebar page. So I decided to retry some times until all "tab is created" messages are delivered and processed at the sidebar page.
To be honest, I forgot to think about cases like "some tabs were not tracked by the master process" caused with operations while TST is initializing (because I believed that it is a common sence that "wait until initialization is finished for safety, otherwise everything may become broken".) On such cases the function may fail forever. I hope that the auto-rebuild logic imported from the PR #2239 should work for such cases.
@PowerAccess can you review piroor's comments and recent check-ins to see if we could consider this resolved or not? If so, can you close the item?
@piroor and @irvinm,
Thanks for your help. I've been testing versions from Git and then XPI releases for a while and seems like all major issues are now resolved in v3.0.11 XPI release.