Treestyletab: tab clicks select wrong tabs, after tabs are opened by a keyword javascript bookmarklet

[bughit]

Short description

clicking on a tab in the tst side-bar ends up selecting a tab other then the one being clicked on

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. add a bookmarklet with
   
   
   
   • Location: javascript:open('http://example.com/?%s1');open('http://example.com/?%s2');open('http://example.com/?%s3');open('http://example.com/?%s4');open('http://example.com/?%s5');void open('http://example.com/?%s6');
   
   
   • Keyword: bm
   
   
4. on the home tab invoke this bookmarklet: bm test
5. this opens 6 child tabs under the current home tab
6. start clicking on the new tabs in the side-bar

Expected result

clicked tab to be selected

Actual result

a different tab is selected for most/all tabs

Environment

• Platform (OS): win7 sp1 x64
• Version of Firefox: 64.0
• Version (or revision) of Tree Style Tab: 2.7.9

[piroor]

This problem depends on the performance of the runtime environment. By recent commits TST now tries to synchronize order of tab elements between the background (master) process and the sidebar UI. I hope that it solves problems on your environment also.

[bughit]

@piroor

The problem remains in 2.7.10 perhaps with with more tabs

javascript:open('http://example.com/?%s1');open('http://example.com/?%s2');open('http://example.com/?%s3');open('http://example.com/?%s4');open('http://example.com/?%s5');open('http://example.com/?%s6');open('http://example.com/?%s7');open('http://example.com/?%s8');open('http://example.com/?%s9');void open('http://example.com/?%s10');

I think this is a recent regression, I've been using similar bookmarklets for a long time and only recently noticed these problems.

[kilotaras]

The same thing happens with containers, if tab is reopened in new container. Looks like real order of the tabs and order of tabs shown by TST are different.

e.g. if I only open two tabs s1 and s2, they are in order s2, s1 in top bar bu in order s1, s2 in tree. This can be confirmed by switching tab in the topbar and looking at which tab is selected in tree.

+1 on it being recent, probably less than a month.

[aurelg]

Same here: clicking on a tab in the TST sidebar ends up selecting a tab other than the one being clicked on.

It happens with Firefox 65.0b7, Archlinux, TST 2.7.9 and 2.7.10. Interestingly, it doesn't happen with Firefox 64.0 (same machine, different profile). I have [Auto Tab Discard 0.3.0|https://add0n.com/tab-discard.html] installed in both profile (as well as a couple of other extensions). The problem can be seen even when no tabs are discarded.

I noticed that the tab I click on appears very briefly (<0.5s), and the focus is somehow "changed automatically" to another tab (as if each tab was randomly mapped to another one, to which it is redirected after a very small latency).

I'd be very pleased to help. Should you need more information or test experimental extensions, just ping me. :-)

Edit1: the problem is temporarily fixed if I restart TST with F1, but comes back as soon as I open a link in a new tab with middle click, and only from one of the pinned tabs. When I do that, the newly open tab appears at the bottom of TST. Once reloaded, it appears as the first one (just below pinned tabs). Hope this helps?

Edit2: This issue can also be observed when creating new child tabs from non-pinned tabs. It can be fixed by setting "Insertion position of new child tabs" or "Insertion position of new tabs from pinned tabs" to "No control" or "Insert to the top of the tree". However, it's not very convenient to have new tabs coming on top of other ones. When it's set to "Append to the end of the tree", the new/child tab appear at the end of the tree, but then switching tabs is broken as described in this bug.

[kilotaras]

Older versions still show wrong order but selects correct tab.

Bisecting points to https://github.com/piroor/treestyletab/commit/20aa7b593cdcca75e8200c7bf37c936582e0d9c3#diff-32482cb76ebf6f08f131fb3920595d1cR386 as a culprit.

[piroor]

I think that the commit 20aa7b5 just brings the broken index problem to surface. Before the commit, you might see odd multiselection problem caused by internally broken index of tabs, when you ctrl-click or shift-click tabs.

[bughit]

I think that the commit 20aa7b5 just brings the broken index problem to surface

I have not done a bisection but the specific symptom I reported, tab clicks foregrounding wrong tabs, is a recent regression.

If this is a tradeoff between single tab clicks and multiselection, the bias I think should be for tab clicks, since that's a more fundamental operation without which the browser becomes unusable.

Of course ideally both would be fixed. Is this a solvable problem? or is there something lacking in the api?

[metronidazole]

Being unable to click a tab is a showstopper bug. Being unable to multiselect is nothing in comparison.

[piroor]

Please note that internal index is used in multiple purposes. For example, it is also used to calculate the position newly opened tab to be inserted.

[kilotaras]

This may be useful (from mozilla/multi-account-containers#1030)

Natively in Firefox, when you have a tab at index openerTabIndex, and middle-click several links in it, the links are opened at these respective tab indexes, in chronological order:
openerTabIndex + 1, openerTabIndex + 2, openerTabIndex + 3, ...
Firefox does this until some kind of tab interaction (select, close, etc.) occurs, at which point the reference tab index is reset, and the next background tab is opened at index openerTabIndex + 1 again.

My guess would be that TST isn't tracking reference index reset correctly.

[piroor]

I've introduced more changes to synchronize order (and index) of tabs safely. I hope it is effective for problems like this...
(Testing with development build is welcome: https://github.com/piroor/treestyletab#development-builds )

[kilotaras]

Looks fixed with bookmark. Still present with containers.

Minimum example for second case would be

1. Addons installed: TST (master) + temporary containers.

2. Temporary containers configured to open new links in new containers

   • isolation -> global -> navigating should open new containers

3. Go to news.ycombinator.com

4. Open a bunch of links with middle mouse.

[piroor]

@kilotaras Thanks. On your csae rearranging of tabs was blocked by tabs removed while asynchronous operations. By 5638061 such tabs become ignored and rearranging of tabs looks completely done for me on the case.

[kilotaras]

Can confirm, works with temporary containers. I will keep an eye for odd cases but looks fixed both for this and bookmark scenario.

Thanks for the great extension!

[aurelg]

Thanks for the great extension!

Not to pollute the thread but, honestly, this extension is a real blessing. Thank you so much!

[metronidazole]

The latest dev build appears to have fixed the issue thankfully.

Edit: It broke again.

[cipri-tom]

For me, the version 2.7.16.8089 is still broken, in the sense that some tabs cannot be clicked on. Sometimes, clicking on a tab always takes me 5 tabs lower in the tree (approximately), even though that newly selected tab is from a different tree.

When this started to break, at least a restart temporarily solved the issue (with F1). But now it is no longer the case, and moreover after F1-restart the tree gets scrambled. My tree is a compete mess 😭.

1. How can we go back to a working version? Something, like, December or November 2018.
2. How can we help you fix this?

Thank you!

[bughit]

in the sense that some tabs cannot be clicked on

Have also encountered this, have not gotten around to reproducing reliably

[cipri-tom]

Maybe this will be fixed in FF65, with the new management using "successorIdx" ?

[piroor]

How can we help you fix this?

To "fix" this problem fundamentally, I think I need to restructure TST completely based on virtual DOM (ReactDOM). Currently TST tracks changes of Firefox tabs by both sidebar pages and the background page, but for more stability I need to track Firefox tabs only on the background page and making the sidebar page just a view. It is just a plan and sadly I have less time to do that for now.

[metronidazole]

@piroor

But it was working fine beforehand?

If we were to pay you to spend time to fix this, how much would you need?

[piroor]

But it was working fine beforehand?

As I commented https://github.com/piroor/treestyletab/issues/2119#issuecomment-452833788 and
https://github.com/piroor/treestyletab/issues/2119#issuecomment-453010245 , even if you thought that TST was worked fine, it was actually broken internally and other people saw different problems you never saw. What problems appear on your environment is strongly depending on how you use TST (and possibly the performance of the running system).

On my case I don't see problems like this issue anymore by recent changes. But please remind that I don't say that "your usecase is wrong". You just hit the timing issue. Concrete steps (especially, it is quite better if it is independent from system performance) to reproduce the problem on my environment will help me to introduce more (cosmetic) fixes, until I recreate TST fundamentally.

If we were to pay you to spend time to fix this, how much would you need?

Sorry but currently I have no plan to leave from current employer. However, my company provides technical support for Mozilla products and other free sotwares including addons. If any customer asks us to develop TST on our technical support service, I can spent more time to develop TST as my daily work. (Sadly, my company deals only with company customers in Japan...)

[Tragen]

I also have this bug with 2.7.18.
Now I know it's TST. It's not nice but after I figure out that I can restart the tree with F1, it's very easy to do it once a day.

[piroor]

TST 2.7.19 contains a fix about a case after you move a tab from a window to another. On 2.7.18 or older versions, focus of tabs was broken after the "Move Tab to New Window" command. Does the fix affect your case? @Tragen

[tribly]

Sometimes after restarting Firefox a tab gets moved to a child of a pinned tab and the bug happens. After making the tab a parent, all the other tabs work aswell.

[piroor]

This problem (wrong tab focus caused by broken tab indexes) is produced by a mis-sync of multiple asynchronous operations in both the sidebar and the background pages. To resolve that, I'm trying to simplify such operations at #2139. After all migration finished, TST will manage tabs only with the background page, and the sidebar will become just a canvas to render tree of tabs, and such a mis-sync will go away.

[bughit]

Just experienced this again with Fx 63.0.3 and TST 3.0.7, after opening a bookmark folder (open all in tabs) with 44 items grouped.

If you could provide a switch to eliminate this problem at the expense of others ("other people saw different problems you never saw") it would be helpful. Not being able to select a tab is showstopper.

[piroor]

As I commented at https://github.com/piroor/treestyletab/pull/2239#issuecomment-486085560 and https://github.com/piroor/treestyletab/issues/2238#issuecomment-486172115 , I've applied some changes to fix such problems automatically. Could you test the latest development build?: https://github.com/piroor/treestyletab/blob/master/README.md#development-builds

[MurzNN]

Could you test the latest development build?

I test it today, but problem is still here, sometimes I can't select needed tab, after click on tab it selected by short time, but after - select changes to next down tab.

[piroor]

@MurzNN Thank you for testing. Is your case exact same to the one reported at the initial description of this issue? If you've seend the problem with different condition, could you create new issue with detailed descriptions and steps to reproduce on my PC from scratch? (So you may need to narrow down conditions.)

[MurzNN]

@piroor, maybe my problem is other, so I describe it in separate issue: https://github.com/piroor/treestyletab/issues/2241 - if it is same, let's merge them.

[bughit]

Could you test the latest development build?

reproduced in 3.0.8.9044.9044

• the first 3 tabs are ok
• starting with the 4th, a normal fast click briefly switches to the clicked tab, then switches to the one above
• a long click on the tab (> ~1s) gets it to stick (caused by Multiple Tab Handler)

[bughit]

@piroor

This (wrong tab selection after open all in tabs) is consistently reproducible in a new Fx 66.0.3 profile with tst 3.0.7, 3.0.8.9044.9044 nightly, 3.0.8, with "confirm to group tabs" disabled. The problem may start at a different tab on each load. The long click does not select, no Multiple Tab Handler.

[bughit]

@piroor

This (wrong tab selection after open all in tabs) is consistently reproducible in a new Fx 66.0.3 profile with tst 3.0.7, 3.0.8.9044.9044 nightly, 3.0.8, with "confirm to group tabs" disabled. The problem may start at a different tab on each load. The long click does not select, no Multiple Tab Handler.

3.0.9 too

[piroor]

@bughit Could you upload your "prefs.js" for investigation? It won't contain any critical personal data except data stored by legacy addons, but if you mind please send it to me with an e-mail to piro.outsider.[email protected]. (Now I think that tab-related options of Firefox itself may cause the problem.)

[bughit]

@piroor

Sent an email, the zip password is treestyletab (gmail didn't like the attachment until I hid it). However this is a new profile so it seems unlikely that prefs are an issue.

[piroor]

@bughit Thanks. I've checked contents of the file but there looks no changed option related to behavior around tabs. Moreover, I've used the file to launch Firefox but there is no problem...

[bughit]

@piroor

• this is reproducible for me on multiple physical and virtual machines. The hardware is not new, so if this is a question of speed, please try in a vm or slower hardware,
• keep in mind that I am opening a bookmark folder with 44 links, it's possible you need more tabs to repro, but have at least that
• and also that the problem does not manifest on the first tab click, it's better to start clicking from the end

[piroor]

@bughit Thank you for cooperation. After more researching in a case with opening very large number of tabs (I've tried with 75 tabs), I've realized that tab's index can be overwritten unexpectedly with wrong values when tabs are not blank. I couldn't find out the case on my environment because I tested with blank tabs. Could you try the latest development build?: https://github.com/piroor/treestyletab/blob/master/README.md#development-builds

[bughit]

@piroor Tried it several times, seems to be fixed, thank you.

[piroor]

I close this because outdated.