Bug 455747

Summary:	Active tab changes when closing inactive tab by middle button.
Product:	[Applications] krusader	Reporter:	sc <raom.kg1>
Component:	general	Assignee:	Krusader Bugs Distribution List <krusader-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	krusader-bugs-null, nikita+kde, toni.asensi
Priority:	NOR	Keywords:	triaged
Version First Reported In:	Git
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description sc 2022-06-21 19:46:42 UTC

SUMMARY
***
When closing an inactive tab by middle mouse button, the active tab changes. When closing by the close button, the active tab is maintained. I don't know if it's a bug but can't think of why it would behave differently in those cases.
***


STEPS TO REPRODUCE
1. Middle button on an inactive tab


OBSERVED RESULT
See active tab change

EXPECTED RESULT
Active tab is maintained


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 
Debian Sid

KDE Plasma Version: none
KDE Frameworks Version: none
Qt Version: 5.15.2

Comment 1 Nikita Melnichenko 2022-07-31 08:14:41 UTC

Easily reproducible. This should not be happening. Most likely it's a regression in master branch.

Comment 2 Toni Asensi Esteve 2022-07-31 22:47:12 UTC

The bug is present in the "master" branch, the "stable" branch and even in the classic Krusader 2.4.0-beta3 from almost ten years ago. This bug ends up having its difficulties and requiring long investigations...

Comment 3 Nikita Melnichenko 2022-08-08 07:18:51 UTC

(In reply to Toni Asensi Esteve from comment #2)
> The bug is present in the "master" branch, the "stable" branch and even in
> the classic Krusader 2.4.0-beta3 from almost ten years ago. This bug ends up
> having its difficulties and requiring long investigations...

Thanks for checking, Toni!

Comment 4 sc 2023-06-29 18:32:23 UTC

Hi, I just noticed something similar when dragging a tab towards the other panel with the mouse. After the drag is complete, the active tab in the original panel changes to the next leftward tab, which is sometimes not the original tab. This is not a bug and I guess the only way to avoid that would be to differentiate a click+dragging tab action from a click alone. I can open a separate feature request for this if it's preferred