In Wayland only. Copy one entry and paste it. Copy second entry and only first entry is pasteable. History only shows first entry. Disabling Clipboard allows normal copy and paste, but no history. This is the only work-around. Change to an X11 session and Clipboard works normally.
Have you changed any clipboard settings from their default values? Does the issue only happen when copying the things you copied to trigger this issue, or all things you try to copy in all affected software? Can you be specific about what you're copying, and in what software? Does the issue persist in a new clean user account?
Thanks for the response Nate. I am one of the forum moderators at OpenMandriva and since I am the only one with a bugs.kde.org account, I filed it for everyone. This is happening for anyone on OpenMandriva running Wayland with Plasma 6. It happens with upgrades and with fresh installs. It happens with default settings. It works fine with X11. The only work around we have found for the time being is to disable the item in the system tray notifications. That allows the clipboard to work, but with no history. We are aware that this could be completely an OpenMandriva issue and we would gladly work on it, but we do not know where to start. I am not a programmer, but will pass all of this along on our forum. Thanks, Wilson Phillips 145 Bradford Dr Lot 12 Vicksburg, MS 39120 (601) 642-8383 wilsonephillips@proton.me Guarantee does not cover shark bite, bear attack, or children under 5 Sent with Proton Mail secure email. On Wednesday, March 5th, 2025 at 10:39 AM, Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=500927 > > Nate Graham nate@kde.org changed: > > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REPORTED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > CC| |nate@kde.org > > --- Comment #1 from Nate Graham nate@kde.org --- > > Have you changed any clipboard settings from their default values? > > Does the issue only happen when copying the things you copied to trigger this > issue, or all things you try to copy in all affected software? Can you be > specific about what you're copying, and in what software? > > Does the issue persist in a new clean user account? > > -- > You are receiving this mail because: > You reported the bug.
It doesn't seem to matter what is being copied, or from where, or where it is pasted to. You can copy from a file into the terminal, or from the terminal on to the forum page in the browser. You only get one copy and it does not add to the history, so each time you copy and paste, you paste the first and only entry in the history. Thanks, Wilson Phillips 145 Bradford Dr Lot 12 Vicksburg, MS 39120 (601) 642-8383 wilsonephillips@proton.me Guarantee does not cover shark bite, bear attack, or children under 5 Sent with Proton Mail secure email. On Wednesday, March 5th, 2025 at 10:39 AM, Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=500927 > > Nate Graham nate@kde.org changed: > > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REPORTED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > CC| |nate@kde.org > > --- Comment #1 from Nate Graham nate@kde.org --- > > Have you changed any clipboard settings from their default values? > > Does the issue only happen when copying the things you copied to trigger this > issue, or all things you try to copy in all affected software? Can you be > specific about what you're copying, and in what software? > > Does the issue persist in a new clean user account? > > -- > You are receiving this mail because: > You reported the bug.
Yes, it persists on a clean user account. Even from a fresh install. Thanks, Wilson Phillips 145 Bradford Dr Lot 12 Vicksburg, MS 39120 (601) 642-8383 wilsonephillips@proton.me Guarantee does not cover shark bite, bear attack, or children under 5 Sent with Proton Mail secure email. On Wednesday, March 5th, 2025 at 10:39 AM, Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=500927 > > Nate Graham nate@kde.org changed: > > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REPORTED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > CC| |nate@kde.org > > --- Comment #1 from Nate Graham nate@kde.org --- > > Have you changed any clipboard settings from their default values? > > Does the issue only happen when copying the things you copied to trigger this > issue, or all things you try to copy in all affected software? Can you be > specific about what you're copying, and in what software? > > Does the issue persist in a new clean user account? > > -- > You are receiving this mail because: > You reported the bug.
If it's 100% reproducible for all cases for users of a distro, and nobody else, that does make me suspect there's something distro-specific going on. Could be packaging, or default setup, or something else. Do any of the OpenMandriva devs have any ideas?
I have to suspect the same. Right now, no one has any idea, other than we found the work around of disabling the clipboard. We are running 6.3.2 right now, but this was occurring before the latest update. I don't know that we change anything from the defaults in the packaging, but when this is posted, the devs can speak up about it. Any hint as to where we should focus our search? Thanks, Wilson Phillips 145 Bradford Dr Lot 12 Vicksburg, MS 39120 (601) 642-8383 wilsonephillips@proton.me Guarantee does not cover shark bite, bear attack, or children under 5 Sent with Proton Mail secure email. On Wednesday, March 5th, 2025 at 11:22 AM, Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=500927 > > Nate Graham nate@kde.org changed: > > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|WAITINGFORINFO |--- > Status|NEEDSINFO |REPORTED > Summary|Clipboard history won't |On OpenMandriva, clipboard > |hold more than one entry in |history won't hold more > |Wayland |than one entry in Wayland > > --- Comment #5 from Nate Graham nate@kde.org --- > > If it's 100% reproducible for all cases for users of a distro, and nobody else, > that does make me suspect there's something distro-specific going on. Could be > packaging, or default setup, or something else. > > Do any of the OpenMandriva devs have any ideas? > > -- > You are receiving this mail because: > You reported the bug.
Nate, our issue might be a duplicate of this one. https://bugs.kde.org/show_bug.cgi?id=498341 Thanks, Wilson Phillips 145 Bradford Dr Lot 12 Vicksburg, MS 39120 (601) 642-8383 wilsonephillips@proton.me Guarantee does not cover shark bite, bear attack, or children under 5 Sent with Proton Mail secure email. On Wednesday, March 5th, 2025 at 11:29 AM, Wilson Phillips <WilsonEPhillips@proton.me> wrote: > I have to suspect the same. Right now, no one has any idea, other than we found the work around of disabling the clipboard. We are running 6.3.2 right now, but this was occurring before the latest update. I don't know that we change anything from the defaults in the packaging, but when this is posted, the devs can speak up about it. > > Any hint as to where we should focus our search? > > Thanks, > Wilson Phillips > 145 Bradford Dr Lot 12 > Vicksburg, MS 39120 > (601) 642-8383 > wilsonephillips@proton.me > Guarantee does not cover shark bite, bear attack, or children under 5 > > Sent with Proton Mail secure email. > > > On Wednesday, March 5th, 2025 at 11:22 AM, Nate Graham bugzilla_noreply@kde.org wrote: > > > https://bugs.kde.org/show_bug.cgi?id=500927 > > > > Nate Graham nate@kde.org changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Resolution|WAITINGFORINFO |--- > > Status|NEEDSINFO |REPORTED > > Summary|Clipboard history won't |On OpenMandriva, clipboard > > |hold more than one entry in |history won't hold more > > |Wayland |than one entry in Wayland > > > > --- Comment #5 from Nate Graham nate@kde.org --- > > > > If it's 100% reproducible for all cases for users of a distro, and nobody else, > > that does make me suspect there's something distro-specific going on. Could be > > packaging, or default setup, or something else. > > > > Do any of the OpenMandriva devs have any ideas? > > > > -- > > You are receiving this mail because: > > You reported the bug.
Hi, OpenMandriva dev here. We aren't applying any patches to klipper or obviously related bits, so if this is something distro specific, it must be something more subtle, like an interaction with an "unexpected" version of a library or compiler, or a missing optional dependency (I don't see any complaints in build logs), or something along those lines. I can also not reproduce the problem exactly as described here, but I do see a variant -- in the X11 session, everything works perfectly, while in the Wayland session the clipboard seems to misbehave more or less at random, pasting something older than the most recently cut/pasted bit. With klipper disabled, it works perfectly in the wayland session too. So far I haven't seen a pattern to when this happens, but will keep paying attention (and I've switched my default session to wayland now, so I should see it more frequently). At least what I'm seeing might be the same as 498341 -- which is more random than what is originally described here. Wilson: You seem to see this a lot more frequently than I am -- what applications are you using when you're cut&paste-ing?
Thanks for the response Bernhard. As far as I can tell, this appears to be with any/all plasma6 Wayland users. When they select the X11 session, it works perfectly. When they select the Wayland session, klipper will only hold one entry in the history and that is the only entry that can be pasted. Switching sessions is the only change. It does not seem to matter what programs are being copied from or pasted to. Only the one entry in the klipper history is there. One thing to note, if one copies a line in lets use kate as an example and pastes it in another spot in kate it will work, but still no entry is put into the klipper history. This appears to be the same with all apps. They work as long as you stay in that app, even the terminal works this way, but you cannot paste that into another application. Only the one entry in the klipper history is pasted. I looked back through the OpenMandriva forum and this appears to have been happening for at least a few months. I am guessing a dependency issue, but I am not a coder and would have no idea where to start, but I was willing to file a bug report. :-)
Here is something a forum member posted last night. If you use Ctl+C and then press Meta it will load into the klipper. It may or may not load it at the top of the list. I switched over to a Wayland session and was able to verify that it does work that way. It is strange.
I just reproduced this myself on today's git master. It's 100% reproducible in all cases, so definitely not a packaging bug on your side! Pretty much makes the entire history feature broken. Your original case reproduces the issue 100%. Here it is rephrased into a list: STEPS TO REPRODUCE 1. Launch Kate and type anything 2. Copy some text 3. Immediately paste it with Ctrl+V, just to be sure (this works) 4. Copy a different piece of text 5. Press Meta+V 6. Click on the second item in the history pop-up 7. Paste with Ctrl+V again OBSERVED RESULT Nothing happens. EXPECTED RESULT The text gets pasted.
For your step number 6, we can't click on another line of text. We don't see anything but the first entry in the history.
(In reply to Nate Graham from comment #11) > I just reproduced this myself on today's git master. It's 100% reproducible > in all cases, so definitely not a packaging bug on your side! Pretty much > makes the entire history feature broken. Your original case reproduces the > issue 100%. Here it is rephrased into a list: > > STEPS TO REPRODUCE > 1. Launch Kate and type anything > 2. Copy some text > 3. Immediately paste it with Ctrl+V, just to be sure (this works) > 4. Copy a different piece of text > 5. Press Meta+V > 6. Click on the second item in the history pop-up > 7. Paste with Ctrl+V again > > > OBSERVED RESULT > Nothing happens. > > > EXPECTED RESULT > The text gets pasted. Can reproduce, investigating...
(In reply to Wilson Phillips from comment #12) > For your step number 6, we can't click on another line of text. We don't see > anything but the first entry in the history. Hmm, I missed that part, so maybe my issue was different then. Sorry for the noise. Can anyone affected test https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5325?
It was mentioned in bug 498341 that this bug is the one I ran into. I'm no longer able to reproduce this on git-master, Wayland
Cannot reproduce on master either
Can anyone affected test with today's git master? There have been a number of clipboard changes recently.
Looks like there's multiple overlapping issues here. The particular "only one item shows up" issue in this bug turns out to be caused by something else, it is 100% reproducable if QT_QPA_PLATFORM is set to "wayland-egl", but goes away if QT_QPA_PLATFORM Is set to "wayland". A combination of backporting bbecc43cef4e7c615fe8b1691c2eb1e1f916edf3 and 9c014bad595b743de4ca7b236c4d467356505990 and making sure QT_QPA_PLATFORM is set to wayland and not wayland-egl looks like it fixes it for everyone. Not sure if we want to fix the QT_QPA_PLATFORM=wayland-egl case or just tell people not to do that.
That's good news. Do you know why QT_QPA_PLATFORM had gotten set to wayland-egl? Was there a compelling reason for this? I asked around, and folks said the reason for its existence is to support specific platforms where EGL has to be set up before Wayland. The consensus was that it's probably not a good idea for distros to globally set this unless there's a very very good reason. We can keep the bug report open because since it exists and will sometimes be set, it at least shouldn't break the clipboard history this way.
Yes, we set QT_QPA_PLATFORM=wayland-egl in startup scripts when doing the first wayland builds because that's what Qt docs seem to imply is the right thing to do. https://doc.qt.io/qt-6/qtwaylandcompositor-index.html "wayland-egl: This is the default backend and should be preferred whenever possible. It requires support in the OpenGL driver on the system for this to work." I've updated the scripts to say QT_QPA_PLATFORM=wayland, so as far as OpenMandriva is concerned, this shouldn't be a problem anymore.
ok, so the root of the problem ended up being not clear documentation. should we document it somewhere that this should not be done for plasma, except perhaps some selected exotic hardware?
If we had https://invent.kde.org/plasma/plasma-workspace/-/issues/64, I'd put it in there. For now we can also put it in https://community.kde.org/Distributions/Packaging_Recommendations.
Documented in both places. If and when we implement the system misconfiguration detection hub, we can add it there.