Repository navigation
Drag and drop of editor tabs is unreliable #1323
Description
Describe the bug
Cannot reliably organize the editor tabs
To Reproduce
I found a bug report in the old bugzilla from more than 5 years ago that describes almost accurately what happens (again) right now:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=541635#c0
Specifically, you need about 5 tries to be able to move the intended editor tab where you want, because:
- the drag-and-drop action is not detected; clicking on a text line inside that tab before draging seems to help sometimes and also dragging out of the editor area is sometimes helpful, although the latter increases the risk of (3) (below)
- the wrong tab is moved
- there's a chance that all tabs that were sharing the same editor view area with the grabbed tab are moved onto the target view area, thus making impossible to show several (two) files in parallel, in different areas
- you have to fight with SWT in order to make the drop; specifically, I can release the mouse after some graphical effects are painted in the window to confirm that the drag-and-drop action was started, like new area border or tab insertion indicator in the tab band; the mouse pointer rapidly changes from hand to regular pointer or cursor (depending on the hovered widget) and I have to click the left button rapidly 4 times or more in order to happen on a moment when the cursor is a hand and the drop is finally performed.
Behaviours (3) and (4) are the most frustrating.
Environment:
Operating System: Gentoo Linux 2.15
KDE Plasma Version: 6.1.1
GTK+: 3.24.41
Kernel Version: 6.9.7-gentoo (64-bit)
Graphics Platform: Wayland
Graphics Processor: AMD Radeon Graphics
Version since
Eclipse 4.30, got worse in 4.32 (java.vendor.version=Temurin-21.0.3+9)
Workaround (or) Additional context
I strongly believe that the cause is partially the same as that of #589.
I tried to launch Eclipse with GDK_BACKEND=x11 and the drag-and-drop actions work just fine, including those reported in #589, albeit the DND graphical effects are a little bit delayed and somewhat undecided. Actually Eclipse feels delayed entirely but more robust - there are a lot of tiny things that malfunction on Wayland, but I only care about the nuisance reported here.
Activity
gerib commentedon Dec 27, 2024
Same behavior here:
2.1. If outline is shown: release mouse-left at intended target: nothing happens, just the outline remains.
2.2. Have to click inside the outline and hit the Enter key (not the one on the number pad but the main one) afterwards.
As mentioned before this sequence of actions works sometimes, sometimes not. That's very disruptive and annoying.
Happens with:
Linux 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux
Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-28-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz
Memory: 15,6 GiB of RAM
Graphics Processor: NV124
Manufacturer: XMG
Product Name: P7xxDM(-G)
System Version: Not Applicable
After
$ sudo apt full-upgrade,Last updates yesterday (if that matters):
and Eclipse > Help > Check for updates > > No updates found.
Eclipse IDE for Enterprise Java and Web Developers (includes Incubating components)
Version: 2024-12 (4.34.0)
Build id: 20241128-0757
Can someone please add the
#ff0000bug and#ff0000regression label?acarstoiu commentedon Mar 17, 2025
It looks like this is now fixed (probably involuntarily) on Eclipse 4.35, in this configuration:
KDE Plasma Version: 6.3.3
GTK+ Version: 3.24.42
Kernel Version: 6.12.19-gentoo (64-bit)
Graphics Platform: Wayland
Graphics Processor: AMD Radeon Graphics
acarstoiu commentedon Mar 17, 2025
Damn, not yet. The issue with the drop part (item 4 above) still remains, although it's not as hard as it used to be to finish the drag-n-drop operation.