Closed RainerB closed 3 years ago
Code wasn't touched in 2.5.2 regarding copy paste. Does it work at all (ie copy normal text from the application and paste it somewhere)
I'm am running 2.5.2 on Arch Linux KDE and I cannot reproduce. My steps are:
It works as expected.
@droidmonkey Copy and paste in general works without issues (e.g. between Firefox, Geany, Terminal)
On another system (also Fedora 31) and same version (keepassxc-2.5.1-1.fc31.x86_64) it's working as expected. So it seems, this is somehow specific to my current system. It's not really critical as I have a workaround, but I'll try to narrow it down further - might not be related to keepassxc at all...
Short recap. I only can reproduce the issue on my current system, but nowhere else. I have a workaround so I'm just curious why this happens.
Nevertheless a few more details, in case someone else is also affected. It's specific to GNOME (Wayland, default) - with GNOME (on Xorg) no problems. I encounter the problem between keepassxc and Terminal / Firefox / Geany - but it's working with e.g. Libre-Office.
My current workaround is to downgrade to "keepassxc-2.4.3-6.fc31.x86_64" or use the AppImage "KeePassXC-2.5.2-x86_64.AppImage" which works fine.
You should have said you were using Wayland.
I believe you need to install xwayland.
Installing it alone wouldn't solve the problem. You also need to force Qt to use to X11 backend. The reason why 2.4 works is that is that we disabled it for you there due to incompatibilities between Qt and Wayland. Since those issues were fixed, 2.5 enables Wayland support by default.
If you can start 2.4 at all, then XWayland is already installed and all you have to to do is start KeePassXC with the environment variable QT_QPA_PLATFORM=xcb
set.
I have no idea why Copy&Paste isn't working properly on Wayland, but the whole ecosystem still feels rather alpha, which is a shame considering its 10-year history and the urgent need for X11 to die.
I'm using the flatpak build in RHEL8 (default Gnome3 with wayland) and have this same issue after the latest update.
As described in the last comment I am able to workaround the issue by setting QT_QPA_PLATFORM=xcb
but it's kinda awkward to have to do this:
$ flatpak run --command=bash org.keepassxc.KeePassXC/x86_64/stable
$ QT_QPA_PLATFORM=xcb keepassxc
This is not my area of expertise but the fix has to be made in the flatpak packaging, right?
I can't paste into the KeePassXC (Fedora31, Wayland, Flatpak v2.5.2). @ptalbert's workaround works for me.
I had a similar issue that ctrl+b
and ctrl+c
was not working in the following scenario:
I have a record with a url, username and password
URL adresa
link see screenshot first
alt+tab
to go back to KeePassXC ctrl+b
to copy user username (this does not copy user name, because focus is on the URL)This is works as designed, but I did not have this problem in earlier versions of KeePassXC.
I found shortcut ctrl+shift+u
to open url without clicking, then my flow works as expected.
I have Lubuntu 18.04, and KeePassXC 2.5.3
Hi,
I think I'm affected by the same bug: I can paste to KeepassXC as long as I don't copy from KeepassXC. Once I've copied something from KeepassXC, I can no longer paste something to KeepassXC, it always paste the last thing I copied from KeepassXC.
I'm using KeepassXC 2.5.4 from Flathub on a Fedora 32 Silverblue system.
@ptalbert workaround (launching KeepassXC using QT_QPA_PLATFORM=xcb keepassxc
) seems to solve the problem.
Welcome to Wayland...
The following seems to do the trick for me:
cp /var/lib/flatpak/exports/share/applications/org.keepassxc.KeePassXC.desktop ~/.local/share/applications/
chmod 644 ~/.local/share/applications/org.keepassxc.KeePassXC.desktop
sed -ri '/^Exec=/s/(--command=)/--env=QT_QPA_PLATFORM=xcb \1/' ~/.local/share/applications/org.keepassxc.KeePassXC.desktop
Workaround if you have KeePassXC installed as native system package is:
sudo sed -Eri 's/^Exec=(keepassxc.*)/Exec=env XDG_SESSION_TYPE=gtk \1/' \
/usr/share/applications/org.keepassxc.KeePassXC.desktop
I have the same problem here already since months. Distribution is Arch Linux, I am not on Wayland, environment is Kernel: 5.6.15-arch1-1 · KDE-Plasma 5.18.5 · KDE-Frameworks 5.70.0 · Qt 5.14.2
The above mentioned workaround
QT_QPA_PLATFORM=xcb keepassxc
does not have any effect to me; can't still overtake user or password to the clipboard.
launching KeepassXC using
QT_QPA_PLATFORM=xcb keepassxc
Maybe a bit off-topic, but launching KeePassXC in this way on Fedora 32, GNOME Wayland, fixes for me also the window decorations issue 4652.
Not sure if I’m hitting this specific bug ; but my keepassxc started acting up for a few days (weeks max): I could not copy passwords out of keepass (the contents of my clipboard remain to whatever was there before that). Rebooting solved the issue.
I’m using the snap package:
keepassxc 2.6.1 1006 latest/stable keepassxreboot -
My system is
OS: Ubuntu 18.04.5 LTS x86_64
Kernel: 4.15.0-109-generic
DE: MATE
WM: Metacity (Marco)
WM Theme: Ambiant-MATE
Same here already since months. Leading QT_QPA_PLATFORM=xcb
on launch didn't change anything, Version is also 2.6.1
Systeminformation:
Operating System: Arch Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.8.7-arch1-1
OS Type: 64-bit
For those using the Flatpak, a simple workaround:
QT_QPA_PLATFORM=xcb
(as proposed in https://github.com/keepassxreboot/keepassxc/issues/4105)On Fedora 33, the workaround was editing these two lines in /usr/share/applications/org.keepassxc.KeePassXC.desktop :
Exec=QT_QPA_PLATFORM=xcb keepassxc %f
TryExec=QT_QPA_PLATFORM=xcb keepassxc
On Fedora 33, the workaround was editing these two lines in /usr/share/applications/org.keepassxc.KeePassXC.desktop :
Exec=QT_QPA_PLATFORM=xcb keepassxc %f TryExec=QT_QPA_PLATFORM=xcb keepassxc
This doesn't work on my Fedora 33, after I have changed the desktop-file keepassxc icon disappeared from app list in Gnome. I tried different fixes and this one is helped me
Exec=env QT_QPA_PLATFORM=xcb keepassxc %f TryExec=keepassxc
Both of the mentioned workarounds don't work fo rme. As told before, neither username nor password will be copied to the clipboard using Ctrl+B or Ctrl+C or the associated buttons.
Sadly, it stopped working for me on Fedora 34 Beta, too. Even worse, I can't even type into some fields at all now, including the TOTP registration code.
On Fedora 33, the workaround was editing these two lines in /usr/share/applications/org.keepassxc.KeePassXC.desktop :
Exec=QT_QPA_PLATFORM=xcb keepassxc %f TryExec=QT_QPA_PLATFORM=xcb keepassxc
This doesn't work on my Fedora 33, after I have changed the desktop-file keepassxc icon disappeared from app list in Gnome. I tried different fixes and this one is helped me
Exec=env QT_QPA_PLATFORM=xcb keepassxc %f TryExec=keepassxc
This one seems to work for me on f34 beta - It brings back the icon and I can type in the TOTP registration again.
Editing these two lines in /usr/share/applications/org.keepassxc.KeePassXC.desktop
Exec=env QT_QPA_PLATFORM=xcb keepassxc %f
TryExec=keepassxc
Fixes the bug on F33. Thanks @Ingvin.
This was a bug in Fedora distribution, closing this one.
I still experience the issue that CTRL-C is not working on Fedora 34. Do you have a link to a Fedora Bugzilla report, I could not find it.
It was discussed over irc. Either way this can't possibly be our bug, we just tell Qt what to put in the clipboard and Qt handles it. As you can see the fix above is telling Qt to use the xcb platform plugin to fix the issue, which is probably within the wayland platform plugin.
@janvlug - It's been patched on Fedora 34. If you haven't done an update in a while, it's a good time to do it: https://bugzilla.redhat.com/show_bug.cgi?id=1925130
This happened to me with KeePassXC running on Fedora 34 under Wayland, packaged as keepassxc-2.6.6-1.fc34.src.rpm (so I think newer than the version @vwbusguy mentioned). I couldn't paste a lot of text (~1000 lines, 76,935 bytes) into KeePassXC from the Konsole terminal or wl-copy
.
The workaround for me was to paste the text into another application (I used Kwrite), then copy from that and paste into KeePassXC.
However, now I've restarted KeePassXC, (same version of all packages) I can't reproduce the problem. I tried @yann-soubeyrand 's suggestion to break paste:
I think I'm affected by the same bug: I can paste to KeepassXC as long as I don't copy from KeepassXC. Once I've copied something from KeepassXC, I can no longer paste something to KeepassXC, it always paste the last thing I copied from KeepassXC.
but large pastes into KeePassXC continue to work. So this bug is clearly intermittent.
It's either a bug in qwayland or wayland itself. I'd vote for the former. It's definitely not our bug.
Editing these two lines in /usr/share/applications/org.keepassxc.KeePassXC.desktop
Exec=env QT_QPA_PLATFORM=xcb keepassxc %f TryExec=keepassxc
Fixes the bug on F33. Thanks @Ingvin.
Worked for me on Kubantu 21.10, thanks. Also necessary to update ~/.config/autostart/org.keepassxc.KeePassXC.desktop if it is being autostarted
I'm hitting this same issue on Arch Linux. Did anyone narrow it down where exactly the bug is and submitted bug report upstream?
It's incredibly strange bug. So I have Firefox and KeePassXC both running under Wayland. I can copy from KeepassXC to Firefox, but I can't copy from anywhere* into KeePassXC.
Okay even stranger, I just got it working by trying to copy between random apps so looks like it breaks only sometimes, even weirder....
That usually means you are running most of your applications under X11 through the xwayland bridge which won't share the clipboard.
That's the thing, it's not the case here, I have pretty much everything running under Wayland including KeepassXC and Firefox and other programs. I've very very few using XWayland and copying from XWayland to Wayland and vice versa works perfectly fine.
@davispuh open up Flatseal and enable the "fallback X11" socket permission. That fixed the issue for me under Plasma Wayland on Fedora Kinoite.
I'm not using Flatpack, but native packages on Arch Linux and also it happens only sometimes that it doesn't work.
This was a bug in Fedora distribution, closing this one.
Nope, happens on Arch Linux for me too, unless I start with the aforementioned ENV. Can you reopen this because this is clearly not solved everywhere?
It's either a bug in qwayland or wayland itself. I'd vote for the former. It's definitely not our bug.
I'd be happy to report this downstream, but I'd first have to know what exactly to report. Maybe you @droidmonkey can describe exactly what's happening or how we should debug this?
You have to understand how the clipboard works on Wayland. Only the active app can put stuff on the clipboard (based on our observations). Also, apps that run through a wayland bridge like xwayland or qwayland can have their own bugs in the bridge that have nothing to do with the application you observe the bug in.
What I think the problem is... KeePassXC clears the clipboard after a set time (usually when in the background) using a blank string (not relevant). Since wayland doesn't allow clipboard actions on the non active app I think that puts us in a fail state. That fail state can be cleared if you copy something to clipboard in keepassxc when it's active. This, to me, leads me to believe it is a qwayland bug. We literally just use Qt api to interact with the clipboard.
I can confirm the above on Arch Linux, copying from within KeePassXC does make it work for that session.
Can this issue be reopened or should I create a new one?
This isn't our bug: https://github.com/keepassxreboot/keepassxc/issues/8884#issuecomment-1368032644
Just came across this as well. For a couple of days i was using suspend
to "shutdown" the system. And now i noticed that pasting does not work.
Killing the KeePassXC and running it again solved the issue.
Running Sway with xwayland disable
(pure Wayland). Fedora 37.
What I think the problem is... KeePassXC clears the clipboard after a set time (usually when in the background) using a blank string (not relevant). Since wayland doesn't allow clipboard actions on the non active app I think that puts us in a fail state. That fail state can be cleared if you copy something to clipboard in keepassxc when it's active. This, to me, leads me to believe it is a qwayland bug. We literally just use Qt api to interact with the clipboard.
Had thought the behaviour I was seeing was somehow random, but looks like you're correct here - selecting and copying some random text within KeepassXC does indeed allow me to copy from another program and paste into KeepassXC again.
It's a bug in wayland or qwayland when an app puts blank string on the clipboard. This isn't a keepassxc bug, but we trigger one because of our clipboard handling. This is solved in a recent PR.
Above-mentioned PR: https://github.com/keepassxreboot/keepassxc/pull/9148
Expected Behavior
Copy and paste (crtl-b/ctrl-c) of usernames/passwords works as expected.
Current Behavior
Suddently it was no longer possible to copy and paste (crtl-b/ctrl-c) usernames/passwords. It worked before without any issue. A reboot didn't help.
Possible Solution
As a workaround I downgraded keepassxc (from keepassxc-2.5.1-1.fc31.x86_64) to keepassxc-2.4.3-6.fc31.x86_64 and now copy/paste works again as expected.
Steps to Reproduce
It's interesting that is was working with 2.5.1 before. A reboot didn't help and also (re-)moving "~/.config/keepassxc" (so it was newly created) didn't help.
Environment
Operating system: Fedora 31 (gnome) CPU architecture: x86 Kernel: 5.3.16-300.fc31.x86_64