| Summary: | Despite moving a file/folder on the desktop, the file/folder often jumps back to its prior position automatically | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | kimimaru |
| Component: | Folder | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fernandommuniz, hein, kde, kdedev, nate |
| Priority: | NOR | Keywords: | regression |
| Version: | 6.1.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-desktop/-/commit/80bbe282b227fb4c4ab8ccaed3d06a1b6d64904e | Version Fixed In: | 6.2.0 |
| Sentry Crash Report: | |||
| Attachments: |
A video of the bug in action. Notice how the file moves back to its prior position without any input.
webm version of the above video so it can be previewed in the browser. |
||
|
Description
kimimaru
2024-08-12 17:16:21 UTC
Created attachment 172553 [details]
webm version of the above video so it can be previewed in the browser.
I added the video as a different format for direct preview in the browser.
Also, I'm running the Plasma Wayland session. I have started being able to reproduce this recently. I haven't yet found the pattern, though. I still haven't found a 100% reproducible case, but looking through recent git commits, I found https://invent.kde.org/plasma/plasma-desktop/-/commit/4da2346e42302349422cf7c45e64e838fb4d630f which looks suspicious and the timing roughly lines up with when I recall this beginning to happen. David, does this look like it might be related? I am able to reliably trigger this behavior On one display I have 8 icons in a row on the top The first / leftmost one is a shortcut to Downloads I moved it 2 rows down and after the last icon up top When I try to drag and drop it back in the upper left corner, it snaps back as soon as I click on the desktop Or... it does move back but then when I drag and drop it elsewhere, it snaps back to the top left corner as soon as I release the mouse While it doesn't happen with every move, it does happen with most I can reproduce that too! A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2481 Git commit 80bbe282b227fb4c4ab8ccaed3d06a1b6d64904e by Nate Graham, on behalf of David Edmundson. Committed on 30/08/2024 at 03:51. Pushed by ngraham into branch 'master'. Folderview: Avoid two way sync of positions Positions are stored in the class Positioner. Items on screen follow this property. When it changes a timer is started and we sync to the configuration file. There was existing code to also handle the configuration file changing and re-sync back to Positioner in a circular trip. Due to the timer this isn't always in sync if multiple moves are performed quickly and data is lost. There is no need to update our current state on this configuration changing, it's not something a user can manipulate externally. It seems it was added by accident. Positioner is now the one source of truth and the configuration file is only used for the initial load or resolution changes. M +0 -4 containments/desktop/package/contents/ui/FolderViewLayer.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/80bbe282b227fb4c4ab8ccaed3d06a1b6d64904e *** Bug 489754 has been marked as a duplicate of this bug. *** |