Bug 431902

Summary: Plasma freezes when editing a desktop file through GUI
Product: [Frameworks and Libraries] frameworks-kio Reporter: Antti Savolainen <antti.savo>
Component: Properties dialogAssignee: KIO Bugs <kio-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: faure, kde, kdelibs-bugs, nate, nicolas.fella, plasma-bugs
Priority: HI    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: https://invent.kde.org/frameworks/kio/commit/0300441bb80c3d75a305bc7b1f4a7e1c36f28845 Version Fixed In: 5.79
Attachments: These are the only affected files.

Description Antti Savolainen 2021-01-21 21:47:16 UTC 
SUMMARY
Demonstrative video: https://www.youtube.com/watch?v=GXoRi0bhBoM
I am trying to edit the display name of an application through the GUI. After pressing OK, Plasma freezes almost completely and gets stuck in the "File already exist" dialogue. The only solution is to restart.

STEPS TO REPRODUCE
1. Open Application Launcher
2. Select an entry to edit. In my example I used Steam run in wine, so the .desktop file is in the home directory
3. Edit the "Name:" atrribute in the Application tab

OBSERVED RESULT
The whole Plasma desktop freezes when the "File already exist" dialogue appears

EXPECTED RESULT
The desktop should not freeze

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Comment 1 David Edmundson 2021-01-21 22:51:46 UTC 
From the video we're not frozen, but stuck in a nested event loop.


It is presumably this line here

frameworks/kio

kpropertiesdialog.cpp:1543

KIO::copyJob...
....
QEventLoop eventLoop;
eventLoop.exec(QEventLoop::ExcludeUserInputEvents);

Event loops from plasma are bad anyway, but with this one if the copy job prompts, it won't handle the user event.

We're best trying to port away from the event loop if that's possible within the API
Comment 2 Nicolas Fella 2021-01-21 23:15:32 UTC 
I just came to the conclusion as David.
Commenting out the line makes the dialog responsive again, although the rest of Plasma is still blocked, but that is probably expected since Dolphin behaves the same
Comment 3 Antti Savolainen 2021-01-21 23:32:52 UTC 
Created attachment 135046 [details]
These are the only affected files.

So it seems that only .desktop files inside another folder inside ~/.local/share/applications are affected. None of the files in the root folder cause the loop.
Comment 4 David Redondo 2021-01-25 08:18:23 UTC 
I can make Dolphin freeze the same way by just creating a file called "a" and one named "aa" and then trying to rename it to "a"
Comment 5 David Redondo 2021-01-25 08:24:47 UTC 
Even bin/kpropertiesdialogtest locks up itself
Comment 6 David Redondo 2021-01-25 09:14:49 UTC 
Bisected to 4c12899369f43009269d0fdb80964483365bb922
Comment 7 Bug Janitor Service 2021-01-25 11:40:40 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/324
Comment 8 David Redondo 2021-01-25 23:06:15 UTC 
Git commit 0300441bb80c3d75a305bc7b1f4a7e1c36f28845 by David Redondo.
Committed on 25/01/2021 at 11:26.
Pushed by dfaure into branch 'master'.

Fix lockup when renaming a file from properties dialog

4c12899369f43009269d0fdb80964483365bb922 changed how we show the rename dialog.
Before we would exec() it and now we call show(). This causes a lockup when
renaming a file from the properties dialog to a filename that already exsist.
Optimally we would change KPropertiesDialog to make it async and not use nested
event loops but this fixes the lockup for now.

M  +2    -2    src/widgets/kpropertiesdialog.cpp

https://invent.kde.org/frameworks/kio/commit/0300441bb80c3d75a305bc7b1f4a7e1c36f28845