SUMMARY Plasma Clipboard Widget Erratic STEPS TO REPRODUCE 1. Press Ctrl-C or Ctrl --X over a highlighted object (eg text) 2. Check the Clipboard list and notice that the copied text doesn't always appear. 3. Press Ctrl-V and the resulting text pasted may or may not be the text just copied. 4. Sometimes the text pasted is from an earlier session. OBSERVED RESULT Clipboard performance is erratic. EXPECTED RESULT Clipboard should paste the item at the top of the list or the item selected. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 25.04 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 ADDITIONAL INFORMATION None
There's not much we can do with the report in it's current form without any sort of pattern or reproducer. >1. Press Ctrl-C or Ctrl --X over a highlighted object (eg text) If this does not update the clipboard the number one cause would be the client you're copying on. Can it be narrowed down to any app? The kwin debug console can be found by typing "kwin" into krunner. That has a tab for clipboard. Is this correct? Does removing the system tray clipboard applet make a difference in how things get copied?
Created attachment 182269 [details] Full screenshot of my desktop This shows the Console content and the Clipboard icon, just after a Ctrl-C.
I've removed the Clipboard applet as suggested, but it is probably too soon to know if it has changed anything. I will report back when I've done more work.
Ok, so a few things to note: 1) kwin things the contents are coming from an Xwayland application I assume you copied from Chrome. Is chrome running in X11 mode? A quick test is to run xprop and hover over chromium, if the cursor becomes a + shape, then it's in X. If not... do you have an X11 clipboard manager running in the background?
I ran xprop and confirmed that Chrome appears to be running in X11 mode. I assume that this is the situation after an upgrade from an earlier version of Kubuntu; I did nothing (AFAIR) to cause this. Should I be taking steps to run Chrome under wayland? Kubuntu 25.04 was not the first version to switch to wayland; I think that happened with 24.10, or even earlier (I recall some things no longer being available after the switch (such as nvidia proprietary drivers)). The problem under discussion didn't happen until much later. By the way, since I removed the Clipboard applet, copy/paste seems to be working, but of course I've lost access to the historic objects held in the list. Should I put it back or carry on as is for a while longer?
I tried putting the Clipboard Applet back and the behaviour returned. There was a slight change; the paste buffer clearly contained the password that I had just copied from kwallet, but the Clipboard list did not. Previously, the Applet didn't have the most recently copied object in the list *and* the paste buffer appeared to contain an object from an earlier action.
David, I just stumbled across this bug report in the Mandriva Forums from March. They seem to have found a workround and a solution for this, but I can't say I understand enough about what they have done to try it here. However, it may help you to isolate this problem on Kubuntu.
Can you provide a link to it?
I thought I had ;-( I'm not at home right now, so I can't find it my browser history. As soon as I have time, I'll post it; probably tomorrow now.
Here is the link to the Mandriva report: https://forum.openmandriva.org/t/kde-clipboard-not-working-in-wayland-bug-reported/6782
I don't know if this is relevant, but I started to look around the installed clipboard and wayland related items on this machine: terry@OptiPlex:~$ apropos wayland wayland-info (1) - display information utility for Wayland wl-clipboard (1) - Wayland copy and paste command line utilities wl-copy (1) - Wayland copy and paste command line utilities wl-paste (1) - Wayland copy and paste command line utilities wlfreerdp3 (1) - FreeRDP wayland client Xwayland (1) - an X server for running X clients under Wayland. I noticed that there are three items listed that are related to the clipboard and checked to see if I had them: terry@OptiPlex:~$ sudo apt install wl-clipboard wl-clipboard is already the newest version (2.2.1-2). Summary: Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 1 terry@OptiPlex:~$ sudo apt install wl-copy Error: Unable to locate package wl-copy terry@OptiPlex:~$ sudo apt install wl-paste Error: Unable to locate package wl-paste It would seem logical that wl-clipboard would be relying on wl-copy and wl-paste to work, but Kubuntu doesn't seem to have them in it's repositories. Or have I missed something?
The issue in that particular case was also traced to a distro setting incorrect environment variables. Please let us know if you can get a 100% reproducible case on your own system.
I'm not sure if my problem can be described as reproducible, in that I don't know what steps would reproduce it on another's system. Also, the problem is not consistent, even on here. Yesterday, nothing was finding its way into the Clipboard list. So far today, everything is. The only difference today is that I booted this system less than 15 minutes ago, whereas yesterday the machine had been running for several hours. Maybe something that I routinely use 'steals' the clip buffer from Clipboard? Yesterday, I upgraded my laptop to 25.04 and didn't see the problem. However, I usually use my laptop for different things to my desktop, so the problem may raise it's head one day,
I have a bit more info. As related earlier, I saw no problems with copying text to the Clipboard first thing this morning. At that point I had only used Chromium and no other software other than the packages that are loaded as part of boot-up. A few minutes ago, I tried copying from various sources, with no problems after copying from other sites, LibreOffice and kate. Then I tried copying a password from kdewallet and the new text did not appear in the Clipboard list. Not only that, when I tried to paste the copied password into kate, I got the previous string and not the required password. In other words; the bug originally reported. Hopefully others may be able to reproduce this.
*** Bug 505957 has been marked as a duplicate of this bug. ***
My apologies! I opened 505957 because this one blamed Clipboard, whereas I now think the problem may lie in KWallet. I wanted to ensure that the maintainers of KWallet got to see it.
I think I may have this bug 100% reproducible on one system, but I don't have it on any other systems. I'm not sure where to look farther. I am willing to open a new bug report if you think it's not this one. For me, the first thing that goes into the clipboard history is the only item that enters. After that when I copy and paste it briefly is in the clipboard (But not the widget!) and I can see it in Kwin Debug or I can paste it. But after a short amount of time, whatever is the last entry in the clipboard history replaces it. If I clear the clipboard history then I can copy and paste fine for a bit, until one of the things I copy makes it into the clipboard history, then the situation repeats. When I first started noticing this I had a long clipboard history but no further entries would go in. Now since clearing, I only ever have one entry and it persists until clearing. This system is on VOID Linux, but I have another system that I beleive to be configured the same also on Void that is not experiencing any issues. I'm at a loss as to where to go to debug farther.
It doesn't appear to be user related. I tried 1) Clearing my .cache, and all klipper, kde, or plasma related files in .local and .config 2) Creating a new user Both had the same behavior persist.
(In reply to rekh127 from comment #17) > I think I may have this bug 100% reproducible on one system, but I don't > have it on any other systems. I'm not sure where to look farther. I am > willing to open a new bug report if you think it's not this one. > > For me, the first thing that goes into the clipboard history is the only > item that enters. After that when I copy and paste it briefly is in the > clipboard (But not the widget!) and I can see it in Kwin Debug or I can > paste it. But after a short amount of time, whatever is the last entry in > the clipboard history replaces it. > > If I clear the clipboard history then I can copy and paste fine for a bit, > until one of the things I copy makes it into the clipboard history, then the > situation repeats. > > When I first started noticing this I had a long clipboard history but no > further entries would go in. Now since clearing, I only ever have one entry > and it persists until clearing. > > This system is on VOID Linux, but I have another system that I beleive to be > configured the same also on Void that is not experiencing any issues. I'm at > a loss as to where to go to debug farther. I fixed it by forcing a reinstall of all files of all packages the plasma meta package depends on (full dependency tree). Unfortunately while I had intended to snapshot before so I could do a diff and see what files might be the cause if it fixed it... I snapshotted the wrong filesystem. *sigh*
I'm the original reporter of this problem and my system still exhibits it. I am quite happy to try to establish the guilty file, but I'm not sure exactly how. (In reply to rekh127 from comment #19) > I fixed it by forcing a reinstall of all files of all packages the plasma > meta package depends on (full dependency tree). I ran apt-cache depends plasma-desktop plasma-desktop and got a huge list (and I'm not even sure that plasma-desktop is the right package I couldn't find the meta package that you referred to. > Unfortunately while I had intended to snapshot before so I could do a diff > and see what files might be the cause if it fixed it... I snapshotted the > wrong filesystem. What command did you use to snapshot the file system? I've used the default Backup program in Kubuntu for years, but that creates an enormous list of targz files, which are unlikely to be of much use without a lot of effort. I'm also aware of rsync, but never used it. If you could provide a reasonably detailed set of steps. I'll run it and see what pops out.
(In reply to Terry Coles from comment #20) > I'm the original reporter of this problem and my system still exhibits it. > I am quite happy to try to establish the guilty file, but I'm not sure > exactly how. > > (In reply to rekh127 from comment #19) > > I fixed it by forcing a reinstall of all files of all packages the plasma > > meta package depends on (full dependency tree). > > I ran apt-cache depends plasma-desktop plasma-desktop > > and got a huge list (and I'm not even sure that plasma-desktop is the right > package I couldn't find the meta package that you referred to. > > > Unfortunately while I had intended to snapshot before so I could do a diff > > and see what files might be the cause if it fixed it... I snapshotted the > > wrong filesystem. > > What command did you use to snapshot the file system? I've used the default > Backup program in Kubuntu for years, but that creates an enormous list of > targz files, which are unlikely to be of much use without a lot of effort. > I'm also aware of rsync, but never used it. If you could provide a > reasonably detailed set of steps. I'll run it and see what pops out. My system is on zfs and voidlinux so not really easy to translate to kubuntu on ext4. I just figured out what was causing mine. Mine was caused by an environment variable I set long ago, that got cleared by my update. And then I found this: https://bugs.kde.org/show_bug.cgi?id=500927 (edit: Oh ... I just realized this came full circle because you posted about the mandriva bug earlier.) to see if this is whats causing it for you, can you check the environment variables when it starts happening next ( the output of command printenv ) ?
(In reply to rekh127 from comment #21) > I just figured out what was causing mine. Mine was caused by an environment > variable I set long ago, that got cleared by my update. And then I found > this: https://bugs.kde.org/show_bug.cgi?id=500927 (edit: Oh ... I just > realized this came full circle because you posted about the mandriva bug > earlier.) > > to see if this is whats causing it for you, can you check the environment > variables when it starts happening next ( the output of command printenv ) ? Well it's still happening, so I ran that and got: terry@OptiPlex:~$ command printenv SHELL=/bin/bash SESSION_MANAGER=local/OptiPlex:@/tmp/.ICE-unix/2496,unix/OptiPlex:/tmp/.ICE-unix/2496 WINDOWID=1 QT_ACCESSIBILITY=1 COLORTERM=truecolor XDG_CONFIG_DIRS=/home/terry/.config/kdedefaults:/etc/xdg/xdg-plasma:/etc/xdg XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 XDG_MENU_PREFIX=plasma- ICEAUTHORITY=/run/user/1000/iceauth_sLWCtA LANGUAGE=en_GB:en SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh SHELL_SESSION_ID=c9847428619346fc99a0c2626746cf63 MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA= DESKTOP_SESSION=plasma GTK_RC_FILES=/etc/gtk/gtkrc:/home/terry/.gtkrc:/home/terry/.config/gtkrc GTK_MODULES=gail:atk-bridge XDG_SEAT=seat0 PWD=/home/terry XDG_SESSION_DESKTOP=KDE LOGNAME=terry XDG_SESSION_TYPE=wayland SYSTEMD_EXEC_PID=2519 XAUTHORITY=/run/user/1000/xauth_lVRYyz XKB_DEFAULT_MODEL=pc105 GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/terry/.gtkrc-2.0:/home/terry/.config/gtkrc-2.0 HOME=/home/terry SSH_ASKPASS=/usr/bin/ksshaskpass LANG=en_GB.UTF-8 LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90: XDG_CURRENT_DESKTOP=KDE KONSOLE_DBUS_SERVICE=:1.127 MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service/memory.pressure WAYLAND_DISPLAY=wayland-0 KONSOLE_DBUS_SESSION=/Sessions/1 PROFILEHOME= XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 INVOCATION_ID=eb624e797af64d51a2fc904ca1a505c0 KONSOLE_VERSION=241203 MANAGERPID=2250 KDE_SESSION_UID=1000 XKB_DEFAULT_LAYOUT=gb LESSCLOSE=/usr/bin/lesspipe %s %s XDG_SESSION_CLASS=user TERM=xterm-256color LESSOPEN=| /usr/bin/lesspipe %s USER=terry COLORFGBG=15;0 QT_WAYLAND_RECONNECT=1 KDE_SESSION_VERSION=6 PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket DISPLAY=:1 GSK_RENDERER=gl SHLVL=1 GSM_SKIP_SSH_AGENT_WORKAROUND=true XDG_VTNR=1 XDG_SESSION_ID=5 XDG_RUNTIME_DIR=/run/user/1000 DEBUGINFOD_URLS=https://debuginfod.ubuntu.com QT_AUTO_SCREEN_SCALE_FACTOR=0 JOURNAL_STREAM=9:24825 XDG_DATA_DIRS=/usr/share/plasma:/home/terry/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop KDE_FULL_SESSION=true PATH=/home/terry/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus KDE_APPLICATIONS_AS_SCOPE=1 KONSOLE_DBUS_WINDOW=/Windows/1 _=/usr/bin/printenv I'm not sure what the Mandriva people were saying (I didn't when I originally mentioned it), but I don't deem to have an environment variable called QT_QPA_PLATFORM, set or otherwise. Is this what you were refering to?
rekh127@gmail.com, it's possible your issue is different from the one that Terry is experiencing. Can I ask you to open a new bug report about it? Thanks.
Terry, can you paste the output of `cat ~/.config/klipperrc`? Also any chance you can create a new user account on the same machine, log into it, and see if it happens there at all?
(In reply to Nate Graham from comment #24) > Terry, can you paste the output of `cat ~/.config/klipperrc`? terry@OptiPlex:~$ cat ~/.config/klipperrc [General] IgnoreImages=false MaxClipItems=50 Number of Actions=0 Version=6.3.4 > Also any chance you can create a new user account on the same machine, log > into it, and see if it happens there at all? I will do that later today. I'll need to populate Klipper with some data and I feel that importing the content of my current Klipper would NOT be a good idea . :-)
(In reply to Terry Coles from comment #25) > > Also any chance you can create a new user account on the same machine, log > > into it, and see if it happens there at all? > > I will do that later today. I'll need to populate Klipper with some data > and I feel that importing the content of my current Klipper would NOT be a > good idea . :-) Well that totally changes everything! First of all the package didn't appear in the Launcher Menu, although the Config item did. I ran that and set the icon to appear in the Task Bar. Still no sign of it. I switched users to check my original installation and when I switched back, it had appeared in the Launcher Menu. I then added the Quicklaunch widget and put the KWalletManager icon into it (because that's how I use it normally). At this point everything was OK. I then tried running cat ~/.config/klipperrc and got a 'file or folder not found message'. I then had a look around and found that there was a kwalletrc file but not klipperrc: Here is what I get in the original login: /home/terry/.config/kstars: terry@OptiPlex:~$ ls ~/.config/kl* /home/terry/.config/kleopatrarc /home/terry/.config/klicketyrc /home/terry/.config/klipperrc terry@OptiPlex:~$ ls ~/.config/kw* /home/terry/.config/kwalletmanager5rc /home/terry/.config/kwin4rc /home/terry/.config/kwin_rules_dialogrc /home/terry/.config/kwalletrc /home/terry/.config/kwinoutputconfig.json /home/terry/.config/kwinrulesrc /home/terry/.config/kwaverc /home/terry/.config/kwinrc /home/terry/.config/kwriterc terry@OptiPlex:~$ cat ~/.config/kwalletrc [Migration] alreadyMigrated=true [Wallet] First Use=false terry@OptiPlex:~$ cat ~/.config/klipperrc [General] IgnoreImages=false MaxClipItems=50 Number of Actions=0 Version=6.3.4
(In reply to Terry Coles from comment #26) and here is what I get when logged into the same machine as the Test User: tuser@OptiPlex:~$ ls ~/.config/kl* ls: cannot access '/home/tuser/.config/kl*': No such file or directory tuser@OptiPlex:~$ ls ~/.config/kw* /home/tuser/.config/kwalletrc /home/tuser/.config/kwinoutputconfig.json /home/tuser/.config/kwinrc tuser@OptiPlex:~$ cat ~/.config/kwalletrc [Wallet] Close When Idle=false Close on Screensaver=false Default Wallet=kdewallet Enabled=true First Use=false Idle Timeout=10 Launch Manager=true Leave Manager Open=false Leave Open=true Prompt on Open=false Use One Wallet=true [org.freedesktop.secrets] apiEnabled=true I hope that helps/
> First of all the package didn't appear in the Launcher Menu, although the Config item did. I ran that and set the icon to appear in the Task Bar. Still no sign of it. Can you clarify what any of this means? What is "the package"? The config item for what? And which icon?
(In reply to Nate Graham from comment #28) > > First of all the package didn't appear in the Launcher Menu, although the Config item did. I ran that and set the icon to appear in the Task Bar. Still no sign of it. > > Can you clarify what any of this means? What is "the package"? The config > item for what? And which icon? OK. I see that I am guilty of a bit of woolly-mindedness. ;-( I was also guilty of conflating KDEWallet with Klipper; simply because the problem appears to manifest itself only when copying from KDEWallet (see https://bugs.kde.org/show_bug.cgi?id=505596#c14 above). Anyway to translate; the package is the Menu Item for launching KDEWallet, the config is the Menu Item for launching the KDEWallet configuration tool and the icon is the klipper icon in the Task Bar. It all came OK after a reboot, apart from the lack of ~/.config/klipperrc, which I feel may be significant. Apologies for the confusion; my 75 year-old brain isn't quite what it was.
No worries, we'll all get there eventually! So you only see this problem sometimes when you're copying a password from KWallet? And never when copying any other text from any other apps or windows? Is that right?
(In reply to Nate Graham from comment #30) > So you only see this problem sometimes when you're copying a password from > KWallet? > > And never when copying any other text from any other apps or windows? > > Is that right? Yes. That is why I queried whether this was really a bug with KWallet when I realised what was happening.
Specifically with KWalletManager, there's an intentional password hint that tells Klipper that this is sensitive information. See bug 156547. However, Klipper could handle that hint better, in a way that's less confusing to the user. Or offer a configuration choice. I don't know if a separate request for that has been posted. I didn't find one.
(In reply to michaelk83 from comment #32) > Specifically with KWalletManager, there's an intentional password hint that > tells Klipper that this is sensitive information. See bug 156547. > However, Klipper could handle that hint better, in a way that's less > confusing to the user. Or offer a configuration choice. I don't know if a > separate request for that has been posted. I didn't find one. Right so this behaviour was added after a request in that bug report. I'm think I understand why but I'm not sure I understand how to work with it. Ever since I started using KWalletManager (probably getting on for 20 years ago now), I've used it as a secure repository for my passwords and other sensitive and / or easily forgotten information. I have to say, I've never really understood any other way to get the password from the wallet to the browser (maybe it worked with Konquerer in the early days, but most of us now use Chrome or Firefox). I now use another password manager, which allows the password to be copied directly to the browser when needed (not Chrome, but another more secure type). However, I am still populating that manager with my hundreds of different credentials that I have built up over the years and my source for this was KWalletManager. Until this change, I could simply paste the credentials into the browser and then save them to the manager. Now this no longer works, I have to paste the credentials into Kate, so that I can then copy them into the browser. Apart from baffling me for many months, I'm not convinced that the security is improved. BTW. This may be the wrong place to ask this question, but if KWalletManager / Klipper prevent credentials being copied, what is the purpose of KWalletManager?
(In reply to Terry Coles from comment #33) > Until this change, I could simply paste the credentials into the browser > and then save them to the new manager. Now this no longer works, > I have to paste the credentials into Kate, so that I can then copy them > into the browser. IMO, there needs to be a complementary change in Klipper, to make things less confusing, and to be able to handle use cases like yours, while still treating the passwords securely. Some password managers like KeePassXC also have other ways of getting user passwords out besides copy-paste. Worst case, you can temporarily unhide the password in KWalletManager, and type it manually where needed. But this is certainly inconvenient and error-prone, so it's only a last resort. Just to confirm, if you copy from KWalletManager, you can still paste the password in kate? If so, that would suggest that the password is actually copied, but just isn't displayed in Klipper. > if KWalletManager / Klipper prevent credentials being copied, what > is the purpose of KWalletManager? It is a very outdated front-end for KWallet. KWallet can also be accessed by client apps through the old KWallet API and, more recently, through the Secret Service API. These allow the client apps to store and retrieve their password automatically, without user action.
Oh goodness, I completely forgot that passeords copied from KWallet intentionally don't end up in the history. Terry, indeed can you confirm that when you copy a password from KWallet, you can actually paste it elsewhere even though it doesn't show up in the history pop-up? If that's what's going on here, then it's really more of a UI issue because it *looks* like something is broken even it isn't.
(In reply to Nate Graham from comment #35) (and also michaelk83 from Comment 34) > Oh goodness, I completely forgot that passeords copied from KWallet > intentionally don't end up in the history. > > Terry, indeed can you confirm that when you copy a password from KWallet, > you can actually paste it elsewhere even though it doesn't show up in the > history pop-up? Yes. Everything else works, it's just Klipper that never sees it. > If that's what's going on here, then it's really more of a UI issue because > it *looks* like something is broken even it isn't. I think that the real problem here is that the KWalletManager / Klipper behaviour was changed, but there was no way for ordinary users to be made aware of it.
Since everything seems to be working, I'm closing this in favor of bug 508326. Feel free to reopen if you have anything more to add here.