Version: 0.9.6 (using KDE 4.5.4) OS: Linux using klipper v0.9.7(not in dropdown menu, unfortunately), if i toggle through the history with the shortcuts for previous/next history item, and i reach the end, the history gets messed up. Sometimes there are only two entries left, sometimes it gets filled up with one of the items a few dozen times. Reproducible: Always Steps to Reproduce: fill the klipper history by marking some entries. use the "next history item" shortcut(default: ctrl-alt-down arrow) to scroll through the list. Actual Results: history is emptied save for two items, or filled to a large size(larger than the size set up for the klipper history) with some random entry or entries. Expected Results: Either nothing happens at all, or klipper jumps to the first entry again.
I failed to reproduce this with klipper 0.9.7 in KDE 4.7.3. Is this still a problem for the reporter in recent version of KDE?
Yes, this problem persists for me in klipper 0.9.7, kde 4.7.3 (ubuntu). I deleted config/klipperrc and share/apps/klipper, to make sure it is not a simple case of old broken config files. It might still be a problem with other kde config files or a result of kubuntu patches.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
This bug is for 4.5.4, not 5.15.3, so I'm marking this as resolved unmaintained. If anyone has a similar issue, please make a new bug report since it's likely that the code involved has changed since this bug was submitted.
Just in case, I did try to reproduce this bug with Plasma 5.26.1 and could not.