Treestyletab: Recent nightlies unable to track new tabs in existing windows

[jryans]

Short description

In recent Firefox Nightly builds (sometime after 2020-03-20 and before 2020-03-28), something has changed such that TST is no longer notified of new tabs in existing windows and gets out of sync with the native tab bar.

Steps to reproduce

1. Open existing profile with TST 3.4.8 in a problematic Firefox version (see above)
2. For some existing window, try to open a new tab

Expected result

TST should show new tabs just like the native tab bar does.

Actual result

TST does not know about the new tab, but the native tab bar does. Also, there are many errors in the Browser Console like:

22:02:35.756
Unchecked lastError value: Error: Script 'moz-extension://1cc30baa-e777-f145-a4d1-772afede4d92/data/vendors/dom-testing-library-event.js' result is non-structured-clonable data index.min.js:13060
22:02:35.759
Unchecked lastError value: Error: Script 'moz-extension://1cc30baa-e777-f145-a4d1-772afede4d92/data/tpl/login.js' result is non-structured-clonable data index.min.js:13060
    createScriptCallback moz-extension://1cc30baa-e777-f145-a4d1-772afede4d92/index.min.js:13060
22:02:35.769
Unchecked lastError value: Error: Script 'moz-extension://1cc30baa-e777-f145-a4d1-772afede4d92/data/js/lib/port.js' result is non-structured-clonable data index.min.js:13060
22:02:35.788
Unchecked lastError value: Error: Script 'moz-extension://1cc30baa-e777-f145-a4d1-772afede4d92/data/js/quickaccess/quickaccess.js' result is non-structured-clonable data index.min.js:13060
22:02:56.901
sendRemoveListener on closed conduit [email protected] ConduitsChild.jsm:108

Environment

• Platform (OS): macOS 10.14.6
• Version of Firefox: Firefox Nightly 2020-03-31
• Version (or revision) of Tree Style Tab: 3.4.8

[jryans]

Aha, hmm, 1cc30baa-e777-f145-a4d1-772afede4d92 is actually Passbolt not TST, so I guess those log lines aren't directly related.

[jryans]

Actually, disabling Passbolt seems to have fixed TST... 🤔 Not sure what that means, but perhaps something has changed in Firefox internals to cause this collision between extensions...?

[jryans]

Ah wait, I take it back, the problem of tabs missing from TST persists even without Passbolt:

22:13:57.354
Promise resolved after context unloaded
26 Configs.js:64
22:14:34.240
can't access property "incognito", tab is undefined background.js:217
22:14:34.240
Unchecked lastError value: Error: Invalid tab ID: 315 background.js:216
22:18:31.636
sendRemoveListener on closed conduit [email protected] ConduitsChild.jsm:108

[piroor]

22:14:34.240
can't access property "incognito", tab is undefined background.js:217
22:14:34.240
Unchecked lastError value: Error: Invalid tab ID: 315 background.js:216

They are not from TST. TST's background.js doesn't do these operations at 216-217.
https://github.com/piroor/treestyletab/blob/master/webextensions/background/background.js#L216

[piroor]

I need concrete steps to reproduce on a clean profile. Could you narrow down the minimum conditions to reproduce the problem?

[jryans]

Aha okay, sorry, I got a bit too excited when seeing the errors in the logs and assuming they suggested a problem that might be obvious. 😅

I'll work on minimising the reproduction steps, it may take me a few days.

[jryans]

So far I haven't noticed a clear set of steps that always triggers this every time, so it's been hard to create the clean profile steps because of that.

I have noticed that when this issue does occur, I can close the sidebar hosting TST and reopen it, which gets TST back to working for a little while in that window, but eventually something happens and new tabs go missing again.

I'll keep working on better repro steps.

[jryans]

At the moment, it feels like the connection between a given window and TST expires or times out when the browser window has been used after a few minutes.

I'll probably need to bisect Firefox builds to get a better idea of what changed here.

[jshap70]

idk if it will help, but for me it's not just that it loses track of new tabs but it acts like it's entirely frozen it's rendering updates entirely. I have some custom css setup to make the close x button only appear on hover and after locking up the x button will never appear even though clicking on the blank spot where it should be will still close the window.

But other than this nothing to add other than to confirm that the behavior seems to trigger either entirely randomly or after some timeout.

[piroor]

Hmm, to be honest I might have seen this problem while I debugged TST. TST's sidebar looked to be disconnected from the background main process, and after reopening the sidebar it worked again. I thought that it was a fragile behavior appearing only when it is loaded from about:debugging, because I've seen the problem only after I reload TST from about:debugging.

If it is a generic problem appearing with a public version of TST, it may be a regression of Firefox itself.

[jryans]

I tried a Firefox regression hunt last night, but unfortunately it failed with both bad and good builds seeming to be good, even though I definitely still see the issue in regular use when not regression hunting...

I used the same profile for both regression hunting and regular use, so currently a bit puzzled. 🤔

[gijsk]

Is there any indication this has started happening on beta, too, and/or do you use something in addition to TST (like some kind of userChrome or other JS) that would cause isConnected to be false on the tabs in the builtin tabstrip? If so, I guess it's possible for this to be related to https://hg.mozilla.org/mozilla-central/rev/fa6696b7ade8 / bug 1624511, though I wouldn't understand off-hand why it wouldn't affect new windows and/or why it'd break newly added individual tabs...

[jshap70]

no, I only have css changes and even then they're very basic.

[jryans]

Is there any indication this has started happening on beta, too, and/or do you use something in addition to TST (like some kind of userChrome or other JS) that would cause isConnected to be false on the tabs in the builtin tabstrip? If so, I guess it's possible for this to be related to https://hg.mozilla.org/mozilla-central/rev/fa6696b7ade8 / bug 1624511

@gijsk Here's the data I've collected so far:

• Copy of my default profile with beta 75: no issue ✅
• Default profile with artifact build of central (should match official Nightly): issue present ⚠️
• Default profile with artifact build of central with bug 1624511 reverted: issue present ⚠️

It would seem there is some issue so far only on the nightly channel, but unrelated to bug 1624511.

At the moment, I still don't have clear repro steps, so I just use the browser for ~10 minutes in a given configuration, after which I usually will have hit the issue if it's going to happen.

I do not use any tab management add-ons other than TST. I do not use any userChrome tweaks.

[jryans]

After some further bisection, I am fairly confident that bug 1316748 (commit https://hg.mozilla.org/mozilla-central/rev/601e0a6a8ee9) is the problematic change.

I have filed bug 1627646 to track the regression affecting TST.

[piroor]

Wow, thanks a lot!

[jshap70]

wow, nice find!

[piroor]

The bug https://bugzilla.mozilla.org/show_bug.cgi?id=1627646 now has a patch and it will become fixed soon.

[piroor]

I close this because the patch has landed to Nightly and the bug has been closed as FIXED.