SUMMARY when I exit KeepassXC after having copied a password to the clipboard, the desktop hangs / freezes for about 5 seconds and then resumes normal operation. STEPS TO REPRODUCE 1. open keepassxc 2. copy password to clipboard 3. exit keepassxc OBSERVED RESULT - keepassxc process exits immediately as expected - keepassxc item stays visible in task bar - desktop is frozen too, cannot interact with desktop items - applications keep working fine, windows can still be moved around i made video showcasing the problem: https://youtu.be/JUjCBmVcyig here is the bug report I originally filed at the keepassxc project: https://github.com/keepassxreboot/keepassxc/issues/6101 EXPECTED RESULT - desktop / task bar not frozen after application exit SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Operating System: openSUSE Tumbleweed 20210208 Kernel Version: 5.10.12-1-default OS Type: 64-bit Processors: 12 × Intel® Core™ i7-9850H CPU @ 2.60GHz Memory: 31,1 GiB of RAM Graphics Processor: Mesa DRI Intel® UHD Graphics 630 I was also able to reproduce this problem an another machine running opensuse leap 15.1 (can post the details if requested)
Xayland or X11? Does it reproduce if you quit KeepassXC without having copied a password to a clipboard? Do you have clipboard actions enabled?
Created attachment 135602 [details] klipper settings
Hi Nate, fan of your blog ;) - I'm using X11 - only reproducible if I copied a password to the clipboard - I'm not familiar with clipboard actions. I looked it up in the settings, I have attached a screenshot I made up some theories in the keepassxc issue, you may not have had the opportunity to have a look. I know keepassxc uses the clipboard feature to hide passwords in the clipboard history, it also clears the password from the clipboard after x secs (10 secs in my case, much longer than the hang). My wild guess is something dbus related :)
is it normal for the bug status to stay at NEEDSINFO WAITINGFORINFO after providing the info? should I move it back to REPORTED now..?
!(In reply to matthias sweertvaegher from comment #3) > Hi Nate, > > fan of your blog ;) Thanks! :) (In reply to matthias sweertvaegher from comment #4) > is it normal for the bug status to stay at NEEDSINFO WAITINGFORINFO after > providing the info? should I move it back to REPORTED now..? You gotta do that yourself. We should probably make the bot do it though. Thanks for the info
This is still an issue on Plasma 5.22.2
For what it's worth, I can reproduce this bug even if no password is copied, such as just opening and closing KeepassXC without doing anything else.
Can confirm this behaviour on debian 11 (x11), too. There is a weird workaround though: 1. open keepassxc 2. copy password to clipboard [&& paste or do other stuff] 3. select another item from the clipboard history 3. exit keepassxc without hanging Operating System: Debian GNU/Linux 11 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-8-amd64 OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz Memory: 7,6 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620
I have this bug too, but my taskbar freezes too even if I do not copy any passwords. Observed it on Kubuntu 21.04 and on Arch with Plasma 5.22.5
Unfortunately, this is still an issue as of Plasma 5.24.5.
(In reply to Mo Kirchner from comment #8) > There is a weird workaround though: > > 1. open keepassxc > 2. copy password to clipboard [&& paste or do other stuff] > 3. select another item from the clipboard history > 3. exit keepassxc without hanging Can confirm that workaround worked well on my end, but I find it very tedious to do those steps after every time I copy a password. I also discovered some interesting observations regarding this behavior: - The KeePassXC process actually exits properly while Plasma (or in my case, Latte Dock) hangs. I did this by running `pgrep keepassxc` in the terminal immediately after quitting the app through normal means (Ctrl+Q, File > Quit, exit from tray icon menu, etc.) - Killing KeePassXC with `pkill keepassxc` or `killall keepassxc` also triggers this bug. But running `pkill -KILL keepassxc` while the app is running won't cause Plasma/Latte to hang, regardless whether or not a password from KeepassXC was copied beforehand. Operating System: Manjaro Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Kernel Version: 5.18.6-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 1600 Six-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 570 Series Note that while writing this comment, Manjaro has not yet upgraded Plasma to 5.25 unless you are in sync with the unstable branch, so I will report back once I have that upgraded, or someone who's already using that Plasma version can try to reproduce this bug again instead.
This issue also found some exposure on the keepassxc side of things [0]. There is some speculation about this being a bug in qt, but nothing definitive. Also keepassxc maintainer mentiones building from dev branch without the delay. I'll quote it here: " I setup a VM with the following; Operating System: Fedora Linux 35 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 Kernel Version: 5.15.14-200.fc35.x86_64 (64-bit) At first I was able to replicate a freeze on exit, but when I did system updates and installed packages required for building keepassxc.... it totally went away. I just built the develop branch and it ran and exited without any delay. " [0] https://github.com/keepassxreboot/keepassxc/issues/5199
interesting, thanks for the update!
*** Bug 463148 has been marked as a duplicate of this bug. ***
Similar behavior has been reported also with LibreOffice and other unlisted apps in Bug 463148. Probably has nothing to do with the password, though maybe still something to do with the clipboard operation.
(In reply to michaelk83 from comment #15) > Similar behavior has been reported also with LibreOffice and other unlisted > apps in Bug 463148. Probably has nothing to do with the password, though > maybe still something to do with the clipboard operation. unfortunately that seems to rule out the Qt fix as the reporter there has Qt 5.15.7 and the dev not able to reproduce used Qt 5.15.2 ..
(In reply to michaelk83 from comment #15) > Similar behavior has been reported also with LibreOffice and other unlisted > apps in Bug 463148. Probably has nothing to do with the password, though > maybe still something to do with the clipboard operation. Can confirm the same behaviour with LibreOffice, couldn't find the Ticket though ;) Hoped this gaines some traction since LO probably has a larger userbase than keepassxc... (In reply to matthias sweertvaegher from comment #16) > (In reply to michaelk83 from comment #15) > > Similar behavior has been reported also with LibreOffice and other unlisted > > apps in Bug 463148. Probably has nothing to do with the password, though > > maybe still something to do with the clipboard operation. > > unfortunately that seems to rule out the Qt fix as the reporter there has > Qt 5.15.7 and the dev not able to reproduce used Qt 5.15.2 .. True. Maybe it's possible to find shared libraries to narrow the search down(?) I'd love to help out on this one, but I have not much experience working with qt/c++ in general. Any pointers welcome!
I added some findings here: https://bugs.kde.org/show_bug.cgi?id=463148 Somebody who knows more about the mentioned connection which times out, could most probably solve the problem :-)!
I was not able to reproduce it using Wayland. But I wasn't able to reproduce it, too, using X11 Gnome ... . I can see it in X11 with nvidia or amd GPU.
@nate I don't think it's correct to change the bug's title to non-intel, i reported the bug on intel gpu. Also, the hang is exactly 5 secs, so I would also remove the 5-10 secs to avoid confusion. To be honest, if the timeout in the duplicate bug report is not 5 secs, it is not the same bug imho.
I added a trace excerpt at the duplicate bug. If you would have read this, you would have seen, that it's exactly 5 sec. 5-10 sec was an initial guess.
I found out what is causing the problem: setting an empty text on the clipboard instead of calling clear(), induces this hang. For more info, see the github comment: https://github.com/keepassxreboot/keepassxc/issues/6101#issuecomment-1376237763
btw, I was also able to reproduce the bug on KDE Neon : Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.7 Kernel Version: 5.15.0-57-generic (64-bit) Graphics Platform: X11 Processors: 6 × Intel® Core™ i7-9850H CPU @ 2.60GHz Memory: 11,7 GiB of RAM Graphics Processor: llvmpipe Manufacturer: innotek GmbH Product Name: VirtualBox System Version: 1.2
Supposed to be fixed in KeePassXC 2.7.5: https://github.com/keepassxreboot/keepassxc/commit/2ee9d501ffdd596cb6de6c368e880e7631ed94dd
(In reply to Hasshu from comment #24) > Supposed to be fixed in KeePassXC 2.7.5: > https://github.com/keepassxreboot/keepassxc/commit/ > 2ee9d501ffdd596cb6de6c368e880e7631ed94dd Incredible, this really fixed the issue for me. Thanks for linking this here!