Treestyletab: v3.0.7 Critically Broken: 1st Tab Never Loads, Last Never Clickable, Wrong Display Order, Clicking Temporarily Activates Wrong Tab, syncTabsOrder() Never Completes, Need Auto Reinit on Mismatched Tabs vs. Thrown Errors

Created on 23 Apr 2019  Â·  10Comments  Â·  Source: piroor/treestyletab

@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.

Related Issues Summarized Here

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).

Summary of New Critical Issues with Latest Version (v3.0.7 from Git)

  1. Tabs Displayed in Wrong Order

    • In the newest of the recent critical issues, Tab display order is now often wrong

    • For example, in the below screenshot, "Amazon.com - Your Subscribe & Save" tab shown is shown at the bottom of TST, when it should be the 2nd tab (after "Home")

    • Also, when I try to click or close the "Amazon.com - Your Subscribe & Save" tab (shown incorrectly at bottom) in TST sidebar, nothing happens.

    • And, other tabs opened later on (as seen in other screenshots further below) also appear out of order, so this isn't just limited to the last tab being wrong.

image

  1. First Tab Never Shown as Loaded

    • Also, the first tab (Walgreens. Trusted) just shows the animated loading favicon and fails to even show the page title ("Walgreens. Trusted" seen in tabbar) and instead just shows the URL, as if it never loaded.

    • See follow-up comment here for detailed Debugging Results and Steps to Reproduce.

    • Notice how the tab had in fact fully loaded (10 minutes before even) without issue as seen in tabbar in this screenshot

    • This issue seems to occur for any tab(s) opened while TST is still initializing (while Sidebar is opening, but before populated with tabs and/or possibly for tabs opened before sidebar even auto-opens on startup)

    • Many "Unchecked lastError" errors also appear in Console immediately before the "Could not establish connecction" error, and, according to discussions I've seen elsewhere for Firefox, all those occur when attempting to send a message when no listener is yet registered.

    • Though no longer seeing "FaviconLoader" error in latest Git commit, which is usually encountered too alongside this, and as is seen in detailed console log entries and debugging results from follow-up comment here

    • This seems related to "Error: Could not establish connection" which occurs in init() in background.js for the sendMessage() call, which fails to go through, and therefore prevents tabs: (which is set via sendMessage) from ever being set initially to window.export(true) results.

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
    });

  1. Background init() error fails to send tabs initially

    • You can see the errors that occurred in below console screenshot which relate to 1. and 2. above, specifically "Could not establish connection" (no listener is registered yet when try to set tabs: via message) and "null has no properties" in Console screenshot, which were only errors in Console at time, and clicking on last tab in TST, for Amazon, did nothing at all.

image

  1. All New Tabs are Tab Mismatch Become Unclickable Too Because syncTabsOrder() Always Fails to Run

    • Even worse, after I tried clicking on any of the newly opened tabs, an unrelated tab gets activated for like 100msec and before switching back to the original tab, and the tab actually clicked on never gets activated.

    • This occurs for any tabs opened in that session after an error / initial out-of-sync / initial mismatch of tab order occurs.

    • After tabs are opened (or possibly after failed click on a newly opened tab), I ended up with 2x "Fatal error: mismatched tabs in the window 1" errors (followed by a 2nd "null has no properties" error) as shown in below screenshot.

    • You can see this as well in how the tab order diffs displayed in "Error: fatal error: Mismatched tabs in the window 1" errors all show the same tab ("+ 3" in this case) remains, even after 20+ calls to syncTabsOrder() (with the mismatched error being logged every 10 failed/aborted syncTabsOrder() calls).

    • Therefore, after one tab gets out-of-sync, all tabs created after that are likewise out-of-sync since that first tab never gets corrected.

    • It seems that syncTabsOrder() never runs, and instead just keeps getting deferred via reserveToSyncTabsOrder() because internalOrder never ends up equal trackedWindow.order (because, it seems, the only place trackedWindow.order is set is in syncTabsOrder() and only if its already equal to that) so that tab order syncing never occurs.

    • After that, clicking most tabs results in first switching to unrelated tab, then switching to unrelated tab (then sometimes to 2nd unrelated tab) then immediately activating the original tab was one before clicking all within 500ms or so.

image

  1. Should Reinit TST for Window after Multiple Failed Attempts (Not Leave All Existing + Even New Tabs Created Days Later to be Broken Too)

    • Instead of throwing Error in syncTabsOrder() after repeated failed attempts to sync tab order there (which not only results in tab mismatch never being corrected, but causes all new tabs after that to be created unclickable or result in wrong tabs activated when clicking them, but even seems to actually further compound the issue and cause other seemingly unrelated errors to occur (as was detailed earlier in #2199), I would suggest instead just reinitializing TST sidebar content (or clearing and recreating the cached tabs) for the affected window.

    • This is important to do in addition to fixing the underlying issues, since it may be expected that such tab mismatch or failed sync errors may occur occasionally or regress over time with changes, and auto-correction is much better than compounded, never-ending inability to use TST whenever this occurs (and even more important since the issues can persist across browser sessions if session restore or Restart Firefox is attempted in order to try to resolve the issues).

    • Question: Which functions can be used to reinit or recreate a sidebar for a window in TST (or even to reinit the entire TST extension for all windows, etc. if possible), so might be able to try in debugging?

My Configuration

  • TreeStyleTab v3.0.7 (Using latest revision "Bump version to 3.0.7" / df57ef9 from Git master)
  • Firefox Nightly v68.0a1 (2019-04-22) (64-bit)
  • Windows 10 x64
  • TST Sidebar auto-opens on startup
  • Almost never use Session Restore (just startup with New Tab empty home page)
  • 'Optimize tree restoration with cache' = disabled
  • Often open many tabs at same time via Open bookmarks folder
  • Often open many (20-100) tabs, and sometimes open quickly (middle clicking on many links)
maybe fixed

All 10 comments

Debugging Results and Errors Summarized from Issue #2199

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.

Complete Console Log

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.

Screenshot of TST Errors in Console

image

image

image

image

Key Errors Occurring with Latest Fixes from Git + Observations

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).

Observations from Debugging and Proposed Changes

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).

Question about syncTabsOrder() Deferred / Cached Tab Sync:

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?

Suggested Alternatives to Reduce Frequency of Issues

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:

Fixes for #2199 (with syncTabsOrder) + many (but not all) of #2238 (v3.0.7 Critical Issues), including:

  • Fixed syncTabsOrder() never actually working (ever) due to always either deferring indefinitely or failing the initial conditions or comparing the wrong things, with a complete rewrite of it
  • Added support for automatic complete rebuild of trees when syncTabsOrder() fails
  • Added "Reload Sidebar" to context menu for sidebar, which users can use when encounter other critical issues like with unclickable tabs, or in wrong order, etc.
  • Fixed "Error: Could not establish connection. Receiving end does not exist" at least when either:
    A. caching is disabled (configs.useCachedTree = false) OR
    B. if configs.useCachedTreeBackgroundExport = false (left = true for now) (not exposed in Options UI)

Steps to Reproduce Critical Issues Fixed in My Pull Request

  • For Firefox Nightly, I open Firefox
  • No session restore, just home page set to just New Tab.
  • With tab caching disabled, with Tree Style Tabs in Separate Window installed, on Windows 10 x64
  • I have TST Sidebar set to auto open on startup
  • I open a few tabs from bookmark bar via middle click to open in new tab, doing so very quickly (eg. more than 1 per second)
  • I open a few tabs via left click also
  • Also open a few tabs via middle clicking on links in page for a couple of the opened tabs
  • 2x "Mismatched tabs" errors appear in Console
  • When clicking most tabs in TST sidebar, some random tab (and sometimes even more than 1) gets activated instead of the one I clicked on, and only for about 100msec temporarily (before jumping back to the tab I was just on)
  • Sometimes clicking doesn't work at all
  • Any new tabs opened after that mismatch error occurred end up unclickable or with wrong tab index
  • Mismatch errors and further unrelated errors (caused by that) end up occurring over time as I try (and fail) to click tabs in TST sidebar to switch to them.

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:

Steps to Reproduce for Remaining Critical Issues (NOT Fixed in My Pull Request)

image

  • For Firefox Nightly, I open Firefox
  • with home page set to just New Tab (no session restore)
  • with tab caching enabled (if you want to see the error)

    • though you can try with disabled if can't reproduce, though after my Pull Request you won't see some of the errors the other issues described below still error when tab caching is disabled)

  • with Tree Style Tabs in Separate Window and Violentmonkey extensions installed (probably not relevant though), on Windows 10 x64,
  • I have TST Sidebar set to auto open on startup
  • Once sidebar is shown, but while still shows loading progress (before fully initialized) I immediately click on a bookmark for:
  • It ends up showing an animated "loading" icon
  • However, in Browser Tab Bar it shows fine, as fully loaded (with title, favicon, etc.)
  • Sometimes it ends up with FaviconLoader error and/or showing URL for tab title (not using page title)
  • Wait even hours later, and still shows it like didn't finish loading
  • Close and reopen Sidebar and still shows like the tab hasn't finished loading
  • See "Error: Could not establish connection. Receiving end does not exist" still occurs when caching is enabled
  • Many "Unchecked lastError" errors also appear in Console immediately before the "Could not establish connecction" error, and, according to discussions I've seen elsewhere for Firefox, all those occur when attempting to send a message when no listener is yet registered.
  • Sometimes (not always) also shows only URL (instead of title) and/or has FaviconLoader error
  • (Once using fixes & enhancements from my Pull Request you can also:) Right click on Sidebar background > Reload Sidebar, and then you will see if that does not fix the tab (still appears as if "still loading" in TST sidebar only, not tab bar).

    • If you modify common.js to set useCachedTreeBackgroundExport = false by default (I a new setting for a new workaround I had implemented in my Pull Request

    • which I suggest making = false by default for everyone once you test it further)

    • then you will see that "Error: Could not establish connection. Receiving end does not exist" no longer occurs.

    • However this does disable import of tabs on startup, but I'm not sure if it fully or partially prevents session restore tab caching from working (for startup only, shouldn't affect after that either way).

    • However, this may also be broken anyways since "Error: Could not establish connection. Receiving end does not exist" error occurs because sendMessage() fails to set tabs: in background init(), like has been doing for long time now.

  • The following code in init() (which I extracted out to exportTabsToSidebar() in my Pull Request) in background.js is what causes "Error: Could not establish connection" (at least when caching is enabled) and seems to prevent prevents tabs: (which is set via sendMessage) from ever being set initially to window.export(true) results.
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
    });

Screenshot of Issue

image

Screenshot of Console Errors

image

Possibly related or separate issue I identified (and only partially fixed) in my Pull Request:

  • sendMessage(kCOMMAND_PULL_TABS) in rebuildAll() in background.js is returning undefined

    • I fixed the undefined variable errors in rebuildAll() by checking for that, but underlying issue remains

    • At least this occurs when rebuildAll() is auto-called early on during init (eg. by reloadSidebars() I believe)

    • This may not be the original cause, but if this is fixed then my new auto-Reload Sidebar logic might help to workaround the issue (Auto Reload Sidebar still seems to help for tab sync, etc. issues that occur after init is completed at least however)

  • You can see the errors that occurred in below console screenshot for "Could not establish connection" (no listener is registered yet when try to set tabs: via message) and "null has no properties" in Console screenshot, which were only errors in Console at time

These replies are possibly outdated, but I wrote them for records of development:


https://github.com/piroor/treestyletab/issues/2238#issue-435920487

  1. Tabs Displayed in Wrong Order
  2. First Tab Never Shown as Loaded
  3. Background init() error fails to send tabs initially
  4. All New Tabs are Tab Mismatch Become Unclickable Too Because syncTabsOrder() Always Fails to Run
  5. 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.

  • Some operations which produce "Could not establish connection" warning on the initialization process are intentional, to minimize the waiting time while the initialization.
    https://github.com/piroor/treestyletab/blob/592b5d3b60a4bf30ea83b7eed632ac93af1a7e77/webextensions/background/background.js#L60-L147
    After the line 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.
  • The "null has no properties" error looks not an error of TST. The URL 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Evotron picture Evotron  Â·  3Comments

stapuft picture stapuft  Â·  4Comments

woj-tek picture woj-tek  Â·  3Comments

emceekain picture emceekain  Â·  3Comments

ElhemEnohpi picture ElhemEnohpi  Â·  4Comments