SUMMARY Dolphin has this rare bug where sometimes when I delete a folder(notably folders) or files, the next file or folder in view somehow gets into a rename operation with the name selection colour and the cursor on the name of the file/folder and gets the deleted item's name when it graphically moves to take the removed item's place. I could get past it by clearing the name of this to-be renamed item which would revert it back to its original name but this has happened a number of times annoyingly enough. STEPS TO REPRODUCE 1. Delete a file or folder in Dolphin 2. See the next folder/file in view get into rename operation when this rare bug triggers Linux/KDE Plasma: KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12 Qt Version: 6.9.0
Not sure if the deletion/renaming operations on the graphical side of dolphin is kio's job.
Created attachment 180532 [details] bug showing rename bug
Dolphin is in icon mode, small icons Right click a file - Move to Wastebin Do the same for a few files Visually it looks like the name of the trashed file is not removed from the view I'm not able to reproduce with Dolphin built from git-master or 25.04.0 in Fedora 42 Given that this is intermittent, I'll leave this open in case someone else ca reproduce it
(In reply to TraceyC from comment #3) > Dolphin is in icon mode, small icons > > Right click a file - Move to Wastebin > Do the same for a few files > > Visually it looks like the name of the trashed file is not removed from the > view > > I'm not able to reproduce with Dolphin built from git-master or 25.04.0 in > Fedora 42 > Given that this is intermittent, I'll leave this open in case someone else > ca reproduce it I found the bug in dolphin 25.04 and in KF6.13 as well, and I think I get how it's happening. Basically you have to "accidentally" invoke a renaming of the file via double clicking it's name which after a second would bring the rename operation, but during that time you'd delete that file and then as it gets to the renaming operation, the file would be trashed and the next one would get it's place.
Created attachment 180549 [details] Bug recreation in GNOME VM Dolphin 25.04 and kf 6.13 This is in a vm but it has gnome as de but has the latest release of dolphin and kf6 where you can see the bug again. My user intuition tells me the renaming operation is not protected from the delete operation correctly or that the mouse click invocation for it has a few problems of how exactly it's called.
Can reproduce what's happening in the video. Usually context menu closes the renaming field, but because the file renaming starts right after the context menu opens, this can happen. dolphin 25.07.70 Operating System: Fedora Linux 42 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.14.2-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/960
Git commit 0f75aa69ea5cd448553d80fc20b172ee5eb28092 by Akseli Lahtinen. Committed on 23/04/2025 at 12:39. Pushed by akselmo into branch 'master'. DolphinView: If contextmenu is requested, abort twoClicksRenaming When using single click to select, user can double click the file to start renaming it. If user at the same time also opens context menu, user can delete the file while the renaming prompt is open, which causes weirdness. This patch makes sure we abort the double click renaming when context menu is requested. M +3 -0 src/views/dolphinview.cpp https://invent.kde.org/system/dolphin/-/commit/0f75aa69ea5cd448553d80fc20b172ee5eb28092
Git commit c883034a0cad596aa407fcd7bf779d3b187e4fd1 by Akseli Lahtinen. Committed on 24/04/2025 at 13:24. Pushed by akselmo into branch 'release/25.04'. DolphinView: If contextmenu is requested, abort twoClicksRenaming When using single click to select, user can double click the file to start renaming it. If user at the same time also opens context menu, user can delete the file while the renaming prompt is open, which causes weirdness. This patch makes sure we abort the double click renaming when context menu is requested. (cherry picked from commit 0f75aa69ea5cd448553d80fc20b172ee5eb28092) 0f75aa69 DolphinView: If contextmenu is requested, abort twoClicksRenaming Co-authored-by: Akseli Lahtinen <akselmo@akselmo.dev> M +3 -0 src/views/dolphinview.cpp https://invent.kde.org/system/dolphin/-/commit/c883034a0cad596aa407fcd7bf779d3b187e4fd1
Sorry for the lateness but thank you Akseli Lahtinen for fixing this. Very appreciated :)