Wrong tab selected after closing, intermittent

[personalmountains]

TST 4.0.18

This feels related to #3559 because I don't think it was happening before 4.0.18, but it's not caused by re-opening tabs. TST just seems to randomly select a different parent when closing a tab. Here's what I know:

• Closing a tab usually selects its parent correctly.
• Once in a while, a different tab is selected.
• It's usually the same wrong tab that's selected every time. I think it only selects a different bad tab when the other one is closed.
• The wrong tab seems to always be in a tree that's collapsed. This might be a coincidence, as most of my tabs are collapsed.

I can't reproduce it consistently, but it happens regularly, maybe after every 20-30 tabs I close. It happens really often.

I caught it once with TST's debug mode enabled. I'm attaching the logs from when I closed the tab, as well as my settings. In the logs:

• I closed tab #4360.
• It should have selected tab #16.
• It selected tab #3392 instead. This tab is always getting selected right now when TST selects the wrong one.
• I see two Tabs.onActivating, the first one is for #16, followed by #3392.

console-export.txt configs-treestyletab@piro.sakura.ne.jp.json

[SHHSSH]

This addon may benefit you, I find it helpful. https://addons.mozilla.org/en-US/firefox/addon/select-after-closing-current/?utm_content=addons-manager-reviews-link&utm_medium=firefox-browser&utm_source=firefox-browser

[piroor]

Thanks a lot @personalmountains ! I've read the log and I've realized some things:

• When the tab 4360 is closed, the tab 16 is focused automatically. The tab 4360 looks to have 16 as its successor tab.
• But immediately the tab 3392 is focused by someone not TST.
• The tab 3392 is under a collapsed tree, so TST expands the tree automatically.

Do you use any other addon which controls focus of tabs after you close the active tab?

[piroor]

BTW I've introduced a fix 1001eb1 for cases when an active last child tab is closed with collapsed children.

[personalmountains]

I haven't been able to reproduce this since I reported it. I don't have any addon that should change the focus behaviour, afaik.

You can close this issue if you want. I'll open a new one if I have more information.

Edit: The problem still happens, but I still don't have more information.

[github-actions[bot]]

This issue has been labeled as "stale" due to no response by the reporter within 1 month (and 7 days after last commented by someone). And it will be closed automatically 14 days later if not responded.

[personalmountains]

It's still happening pretty often. Here's the last log I got, in case you see something new.

My tabs were:

2908
  - 2978
  - 2983
2973

I closed 2983. It should have selected 2978, but it ended up on 2973.

22:25:50.640 common.js:735:13 tst<BG>: 22:25:50.640 background/handle-removed-tabs:
    Tabs.onRemoving  #2983(tracked)
    Object {
        ​byInternalOperation: false
        ​context: 1
        ​isWindowClosing: false
        ​oldChildren: Array []
        ​oldParent: Object { id: 2908, index: 49, windowId: 1, … }
        ​preventEntireTreeBehavior: false
        ​windowId: 1
        ​<prototype>: Object { … } }

22:25:50.641 common.js:735:13 tst<BG>: 22:25:50.642 background/handle-removed-tabs:
    handleRemovingPostProcess
    Object {
        ​children: Array []
        ​closeParentBehavior: 3
        ​descendants: Array []
        ​insertBefore: Object { id: 2983, index: 51, windowId: 1, … }
        ​nearestFollowingRootTab: Object { id: 2973, index: 51, windowId: 1, … }
        ​newParent: undefined
        ​parent: Object { id: 2908, index: 49, windowId: 1, … }
        ​removedTab: Object { id: 2983, index: 51, windowId: 1, … }
        ​structure: Array [ {…} ]
        ​windowId: 1
        ​<prototype>: Object { … } }

22:25:50.644 common.js:735:13 tst<Sidebar-1>: 22:25:50.645 sidebar/scroll:
    tryFinishPositionLocking
    Set [] on tab removed 2983

22:25:50.653 common.js:735:13 tst<BG>: 22:25:50.654 background/handle-tab-focus:
    Tabs.onActivating
    Object {
        ​info: Object { tabId: 2978, windowId: 1, byActiveTabRemove: true, … }
        ​​byActiveTabRemove: true
        ​​byInternalOperation: true
        ​​byMouseOperation: true
        ​​byTabDuplication: false
        ​​previousTabId: undefined
        ​​silently: false
        ​​tabId: 2978
        ​​windowId: 1
        ​​<prototype>: Object { … }
        ​mMaybeTabSwitchingByShortcut: false
        ​tab: "#2978(tracked)"
        ​<prototype>: Object { … } }

22:25:50.654 common.js:735:13 tst<BG>: 22:25:50.655 background/handle-tab-focus:
    tryHighlightBundledTab
    Object {
        ​allowed: undefined
        ​bundledTab: null
        ​oldBundledTabs: Map(0)
        ​shouldSkipCollapsed: false
        ​silently: false
        ​tab: 2978
        ​<prototype>: Object { … } }

22:25:50.660 common.js:735:13 tst<Sidebar-1>: 22:25:50.660 sidebar/scroll:
    renderVirtualScrollViewport
    Object {
        firstRenderableIndex: 0,
        firstRenderableTabIndex: 0,
        lastRenderableIndex: 13,
        lastRenderableTabIndex: 52,
        old: (14) […],
        new: (14) […],
        renderOperations: (1) […],
        scrollPosition: 0,
        viewPortSize: 959,
        allRenderableTabsSize: 447 }

22:25:50.678 common.js:735:13 tst<BG>: 22:25:50.679 background/handle-tab-focus:
    Tabs.onActivating
    Object {
        ​info: Object { tabId: 2973, previousTabId: 2978, windowId: 1, … }
        ​​byActiveTabRemove: false
        ​​byInternalOperation: true
        ​​byMouseOperation: true
        ​​byTabDuplication: false
        ​​previousTabId: 2978
        ​​silently: false
        ​​tabId: 2973
        ​​windowId: 1
        ​​<prototype>: Object { … }
        ​mMaybeTabSwitchingByShortcut: false
        ​tab: "#2973(tracked)"
        ​<prototype>: Object { … }

22:25:50.679 common.js:735:13 tst<BG>: 22:25:50.679 background/handle-tab-focus:
    tryHighlightBundledTab
    Object {
        ​allowed: undefined
        ​bundledTab: null
        ​oldBundledTabs: Map(0)
        ​shouldSkipCollapsed: false
        ​silently: false
        ​tab: 2973
        ​<prototype>: Object { … } }

[piroor]

Thanks! Your log says that TST does two focus moves for 2978 and 2973 when you close a tab by mouse. Hmm, I still cannot imagine why the second operation happens...

[personalmountains]

I'm using Gesturify 2.1.6. I have a gesture "down" to close the current tab, and "up" to reopen it. I use both all the time. Could it be related?

[piroor]

So you closed the active tab with the gesture, when you collected the last log? The log says that the closing of the tab is triggered by a mouse operation on the sidebar. If the problem happened with tab closing by a mouse gesture, TST's wrong internal status may be the trigger of the issue, and we need to find out what produces such a wrong internal state.

[personalmountains]

So you closed the active tab with the gesture, when you collected the last log? The log says that the closing of the tab is triggered by a mouse operation on the sidebar.

I used a down gesture on the page to close the current tab. I did not interact with the sidebar.

If the problem happened with tab closing by a mouse gesture, TST's wrong internal status may be the trigger of the issue, and we need to find out what produces such a wrong internal state.

It's still intermittent and I haven't found what triggers it. If you need me to test anything, just ping me. I'd be happy to help.

[personalmountains]

Just in case you want to try it, here's my configuration for Gesturify. I'm using the right mouse button for gestures.

Gesturefy 2.1.6 Wed Aug 14 2024.json

[piroor]

I've introduced some changes to TST about the point I told above. Now TST wipes internal flags out aggressively, thus such a misdetection should be reduced.

New release with those changes won't be out soon, because I'm continuing dogfooding for safety. If you OK please try the development build.

[personalmountains]

I've installed 4.0.22.1 from f33dab4 for now, I'll see what happens. I'll keep an eye on new commits.

[personalmountains]

As an update, the problem is still present. I changed handle-tab-focus.js to break when the event handler is called twice in less than 100ms. I caught it once so far, but the stack trace is useless and it doesn't tell me the source of the second activation. I've put a bunch of breakpoints into Gesturefy, anywhere it seems to select tabs, just in case. I'll keep digging.

[personalmountains]

@piroor Is it possible that the source is actually Firefox itself? That TST activates a tab too quickly after closing and Firefox activates the tab it really wants right after?

Edit: Nah, it's selecting random tabs.

Edit 2: I'm gonna have to build Firefox from source, aren't I? This thing is driving me crazy.

[github-actions[bot]]

This issue has been closed due to no response within 14 days after labeled as "stale", 7 days after last reopened, and 7 days after last commented.

[piroor]

Is it possible that the source is actually Firefox itself? That TST activates a tab too quickly after closing and Firefox activates the tab it really wants right after?

I thought that but now I think TST may cause such an unexpected focus change triggered by something unknown bug of TST, on some situations especially Firefox and TST is slow. Recent changes I commented above should make logs more clear that what happens when the problem appears.

[SHHSSH]

Is it possible that the source is actually Firefox itself? That TST activates a tab too quickly after closing and Firefox activates the tab it really wants right after?

I thought that but now I think TST may cause such an unexpected focus change triggered by something unknown bug of TST, on some situations especially Firefox and TST is slow. Recent changes I commented above should make logs more clear that what happens when the problem appears.

I think you might be right because over months passed I've noticed peculiar oddities with the selection of tabs after closing, for the life of me I haven't been able to isolate/pinpoint the cause. I'm under the impression it's some options conflicting with one another, but my god, have I tried endless different configurations.

I will figure it out one day and make sure to make note of it because something might be up :|

EDIT - If I'm totally honest with you though, I think that changing it manually a few times within this other add-on's setting
has totally blown my sense of what is "normal" anymore and I just get frustrated occasionally with TST or FF (whichever it is) not being able to somehow recognise the most relevant recently accessed tab. But I suppose such a thing is extremely hopeful to ever really expect, though I've seen some programs implement some form of algorithm that is incredibly capable of such and correct 95%+ of the time it seems from a user perspective. That software was; Alt-Tab Terminator - https://www.ntwind.com/software/alttabter/register.html - it is capable of recognising with extreme accuracy your more relevant last accessed application that you'd be wanting to access.

In fact its functionality of such rather surprised me, as I've not seen much/many/if any other programs/plugins be capable of such, other than IDEs and note taking apps that attempt to do it but(imo) fail miserably for user-friendlyness.

EDIT2 - For others who hadn't known of this add-on also, I've used it for many years now and the developer recently integrated two additional "Recent" tab hotkeys. It is incredibly useful and relevant to this topic somewhat.

[personalmountains]

I'm on 41caa7a.

I just saw something weird: I closed a tab and I saw the active tab switch repeatedly between two tabs. Here are just the events from the console. I selected #833, closed it one second later, then both #845 and #834 flickered. Note the times.

22:56:51.703 Tabs.onActivating  Object { tab: "#833(tracked)",
22:56:52.774 Tabs.onRemoving  #833(tracked) 
22:56:52.777 Tabs.onRemoved: removed  #833(tracked)
22:56:52.781 Tabs.onActivating  Object { tab: "#845(tracked)",
22:56:53.211 Tabs.onActivating  Object { tab: "#834(tracked)",
22:56:53.223 Tabs.onActivating  Object { tab: "#845(tracked)",
22:56:53.298 Tabs.onActivating  Object { tab: "#834(tracked)",
22:56:53.317 Tabs.onActivating  Object { tab: "#845(tracked)",

I'm attaching the full log, but since it doesn't export the expanded objects, I'm adding the same events as above, but with the properties of the info object in case they're relevant:

22:56:52.781 Tabs.onActivating
tab: "#845(tracked)"
​byActiveTabRemove: true
​​byInternalOperation: true
​​byMouseOperation: true
​​byTabDuplication: false
​​previousTabId: undefined
​​silently: false
​​tabId: 845
​​windowId: 1
​​mMaybeTabSwitchingByShortcut: false
​
22:56:53.211 Tabs.onActivating
​tab: "#834(tracked)"
byActiveTabRemove: false
​​byInternalOperation: true
​​byMouseOperation: true
​​byTabDuplication: false
​​previousTabId: 845
​​silently: false
​​tabId: 834
​​windowId: 1
​​mMaybeTabSwitchingByShortcut: false
​
22:56:53.223 Tabs.onActivating
​tab: "#845(tracked)"
byActiveTabRemove: false
​​byInternalOperation: false
​​byMouseOperation: false
​​byTabDuplication: false
​​previousTabId: 834
​​silently: false
​​tabId: 845
​​windowId: 1
​​mMaybeTabSwitchingByShortcut: false
​
22:56:53.298 Tabs.onActivating
​tab: "#834(tracked)"
byActiveTabRemove: false
​​byInternalOperation: true
​​byMouseOperation: true
​​byTabDuplication: false
​​previousTabId: 845
​​silently: false
​​tabId: 834
​​windowId: 1
​​mMaybeTabSwitchingByShortcut: false
​
22:56:53.317 Tabs.onActivating
​tab: "#845(tracked)"
byActiveTabRemove: false
​​byInternalOperation: false
​​byMouseOperation: false
​​byTabDuplication: false
​​previousTabId: 834
​​silently: false
​​tabId: 845
​​windowId: 1
​​mMaybeTabSwitchingByShortcut: false

console-export-2024-8-29_22-59-29.txt

[piroor]

Thanks! Your new log clearly says that you manually clicked multiple times on the tab 834. Hmm...

This kind problems may happen from problems of the mouse or its driver software. Do you see any problem like unexpected double-click reactions on single click? It sometimes happen on my environment when I use wireless mouse.

[personalmountains]

Never. And I didn't click the tab, I used a right-click gesture on the web page to close it.

[piroor]

Hmm, then Firefox or Wayland might produce wrong mouse events with shifted coordinates when you invoked mouse gesture. If you regularly invoke gestures on some area in the contents area, could you try to invoke gestures on different area?

[personalmountains]

It also happens with Ctrl-W.

[piroor]

Same log on Ctrl-W?

[personalmountains]

I'm pretty sure this is caused by the UnloadTabs extension. It's the source of the spurious tab activations. I wasn't aware that it had code that interfered with tab activation.

I also found this bug report from Select After Closing Current (coincidentally recommended by @SHHSSH above) which seems to describe my exact problem. The related bug report on UnloadTabs was never fixed.

I've disabled the "prevent Firefox from loading unloaded Tabs", which was reported to be the cause of the problem, and I'll see if it happens again. If it does, I'll disable the whole extension and test again.

[piroor]

TST has its own similar option "Avoid pending (unloaded) tabs to be activated accidentally on current tab closes or tree collapsing" under the "Tree Behavior" section (please note that you need to unblock expert options.) If you seriously need the option of UnloadTabs extension, try it please.

[personalmountains]

I have not had this problem for two weeks now, so I consider it fixed. The "avoid pending tabs" option in TST also works nicely. You can close this. Sorry for the mess.