[Bug] TST switches tabs sometimes when I click on a webpage

[Tragen]

I'm using FF 116 on Windows and I have a bug that when I click somewhere on a website, the tab switches.
I cannot reproduce it yet, but it happens every some minutes.
TST switches one tab down or up. I have to take care of it the next time it happens.
Anybody else having this problem also?

[piroor]

I've never seen this kind problem. Do you use other addon which provides a mouse gesture feature?

[Tragen]

No I don't have any other addons which handle tabs or anything else regarding this. It happens3 to 4 times a day. I will try to reproduce it.

[piroor]

when I click somewhere on a website

Is this mean you clicked the contents area (below the navigation toolbar, not the sidebar area) ?
Here is the script TST loads into the contents area and it does not handle any mouse event, so TST won't cause this kind problems. Hmm...

[Tragen]

Yes, exactly. It's very strange.

[irvinm]

Only thing I thought might be worth checking are keyboard shortcuts.

Do you have TST keyboard shortcuts set for "Focus to Next\Previous Tab" set? If so, could you have an addon, script, or mouse button action that might be triggering that keyboard shortcut?

There are also keyboard shortcuts for Firefox itself.

[MasterKia]

There's a similar bug that I've been experiencing on and off for several months.
Sometimes when I select a text (mostly in GitHub) and press CTRL+C, this happens (some random tab gets selected):

And the next mouse click or key press (or ctrl+c) might switch to that tab!

This happens occasionally, and a browser restart fixes it until next time.

OS: Fedora 38

[Tragen]

I use CTRL+C a lot, I will try to see if it's my problem also

[ChaseCares]

To provide more information on this issue.

Steps to reproduce are:

1. Create two new Firefox windows
2. In Window A, create a tree like:
   First Tab
   > Second Tab
   by creating a new sibling tab and dragging it onto the First Tab. Opening it in other ways sometimes trigger the issue, but dragging seems to do it every time.
3. While having Window A selected, click onto the TST area on Window B

When you do so, the First Tab in Window A will be selected and navigated to.

To do this repeatedly, create a new child tab in the First Tab tree in Window A, and click back onto the tab area in Window B. It should happen every time.

Edit: Another note is that it doesn't require a mouse event to trigger the bug, it also occurs when using alt tab to which windows.

I also tested this in a new Firefox profile, with only TST installed.

My System:

OS: Arch Linux
DE: Plasma 5.27.7 (Wayland)
Firefox 117
TST Version 3.9.16

Video:

video.webm

[alexUnd]

I had a similar situation - sometimes a new browser window would open when clicking on a tab. It turned out that this was because micro-dragging sometimes happened during the click. I turned off opening a window when dragging and dropping on the browser window and the problem went away

[piroor]

I still couldn't reproduce this problem with:

• Firefox 117 on Arch Linux, Fxfe 4.18, Xfwm4
• Firefox 117 on Ubuntu, Gnome, Wayland

However @ChaseCares's report is suggestive that the problem happens around drag session. Firefox for Linux may have some bugs around drag session operations: sometimes the drag session is not finished correctly with the drag-end. On such situations Firefox forcefully finishes the previous drag session on some next operations: clicking of mouse buttons, and hitting of keys. It can produce calling of callback functions for drag related events on unexpected timings and it may cause problems like reported here.

To reporters: could you collect debug log when the unexpected focus change happens with following steps?:

1. Go to TST's options.
2. "Development" => turn "Debug mode" on.
3. "Development" => "Detailed logging" => turn all checkboxes off.
4. "Development" => "Detailed logging" => turn "Log with timestamp", "sidebar/mouse-event-listener" and "sidebar/drag-and-drop" on.
5. Type about:debugging into the address bar and hit the Enter key to load it.
6. Choose "This Firefox".
7. Find "Tree Style Tab" item under the "Extensions" heading;
8. Click the "Inspect" button.
9. You'll see a debugger for TST. Choose the "Console" tab.
10. Reproduce the problem.
11. After you see the problem, collect logs in the console. (Right-click on the console and choose "Save all Messages to File" for example.)

[ChaseCares]

Thank you very much for your reply Piroor. I think that your suggestion about the drag event is correct, I was initially confused because it appeared that I could recreate the bug without a drag the event, but in actuality it only requires a single event during the windows lifetime to reproduce this bug.

At this point it does seem we are blocked on Bug 1548949? I still went ahead and reproduce the bug with the debugging enabled. I also recorded another video that I believe demonstrates that it is related to the drag event.

Console log:

console-export-2023-9-6_8-50-20.txt

Video:

video.30.webm

[piroor]

Thanks! I've introduced some safe guard mechanisms including 64f9be8. Could you try the latest development build ?

[ChaseCares]

Awesome, I really appreciate your effort. I installed this artifact, it seems the issue is still present, but it appears to not occur on every window change. Before every new tab would cause a switch (after a drag and drop event), now the bug only occurs once per drag and drop event.

So compared to the video in my previous comment, the bug will not occur after the click at 14 seconds, until another drag and drop event.

I went ahead and collected a new log if that would help.

log:

console-export-2023-9-6_17-57-46.txt

Additionally I was able to trigger the same issue by pressing meta key twice, so to trigger the bug it does not require switching between two Firefox windows. And one time it occurred by pressing control, like MasterKia mentioned, but I'm not able to reproduce that one specifically.

Quite a strange issue, thank you.

[piroor]

A "dragover" event looks to be fired, after the drag session is finished and you click another window, on your case. This is a bug of Firefox or the desktop environment. It really breaks consistency of drag events...

Ideas of workarounds:

• Ignoring dragover events for already finished drag events simply. But it looks hard because DOM drag events has no session ID information.
• Tracking dragstart and dragend/drop events with the background page, and ignoring dragover events while there is no tracked living drag session. This may be effective without session ID information, but will break drag reactions for dragging from other applications.

[piroor]

I've introduced more safe guard with the commit a5827b5: it is based on a custom drag session ID. It is not perfect but it should effective for drag-and-drop done in single browser window. Could you try a new development build?

[ChaseCares]

Thank you! I installed this artifact. The issue still occurs and I don't believe it changed.

Log:

console-export-2023-9-7_13-56-4.txt

I'm not sure if it's related/useful, but I also recorded a single drag event and then used the meta key to trigger the issue. If this is the same issue the steps to reproduce it are fewer and simpler to achieve.

Video:

video.webm

Log:

console-export-2023-9-7_14-8-53.txt

[piroor]

Thanks! Hmm... I misunderstood what happened on your environment. Could you try collecting log with a new development build including the commit 8da0e60 ?

[ChaseCares]

Oh sorry about that. Here is the log from artifact.

Log:

console-export-2023-9-7_15-54-9.txt

Let me know if there is any additional information or steps than I could do that would be of assistance. Thank you for your time.

[piroor]

Thanks a lot! The log line tst<Sidebar-1>: 15:54:07.839 sidebar/drag-and-drop: onDragOver: sessionId=, types=, dropEffect=move, effectAllowed=uninitialized common.js:682:13 shows what's the actual problem clearly. It means that the notified dragover event is quite invalid - event.dataTransfer.types for a dragover event must contain one or more data type but actually it is blank on this case. I've re-introduced a safe guard to ignore such invalid dragover events. Could you try a new development build again?

[piroor]

By the way, this "invalid dragover" problem looks should be tracked at https://bugzilla.mozilla.org/ as a bug of Firefox itself. I can't report it because I can't reproduce it on my environment, so I recommend you to report it.

I think such an invalid dragover event may be produced with these triggers:

• Linux desktop environment with Wayland.
• Drag session started and finished on an Web contents. On your case it is TST's sidebar page, and just a simple HTML file may become a trigger also.

If it is hard for you to create a small testcase, I recommend you to add installing a development build of TST (*you should download the XPI because it will be expired soon) and activating debug logging, as required steps to reproduce of the bug. Log line like onDragOver: sessionId=, types=, dropEffect=move, effectAllowed=uninitialized is unexpected on the situation, the expected result is just no event logged.

[ChaseCares]

The safeguard works for me! I cannot reproduce it anymore, thank you very much for putting the time into fixing this, I greatly appreciate it. I we'll work on getting this submitted to mozilla.

Thank you!

[github-actions]

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.

[Tragen]

On windows, I still have the problem with 3.9.17.
It feels like it doesn't happen so often anymore but I need to test more.

[github-actions]

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

[Tragen]

I still have the problem on Windows with FF 118

[piroor]

@Tragen Could you collect logs and screencast when the problem appears, like ChaseCares did?

[Tragen]

The problem is I cannot reproduce it and currently it doesn't happen very often anymore.
Looks like your fixes worked. Perhaps there is one more place you missed.
I will try to get a log and reproduce it.

[Tragen]

I will try but it happened not very often anymore and before your fixes it was already only once or twice a day

[github-actions]

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