| Summary: | Clipboard breaks if application only sends metadata, with other cases where list entries are valid but visually empty | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Soup <bmanbros> |
| Component: | Clipboard widget & pop-up | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | kde, kdedev, nate, qydwhotmail |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | NixOS | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | 2 images side by side depicting both issues described above, one showing a valid copy appearing as an empty clipboard entry, and an empty clipboard entry not appearing at all | ||
How is this then supposed to work? That means cannot paste into other applications as well. (In reply to David Redondo from comment #1) > How is this then supposed to work? That means cannot paste into other > applications as well. For the empty copy bug that is the issue, there is nothing to paste for any application because the only thing in the clipboard entry is metadata, which shouldn't be a valid state. For complex content, pasting still works, it's just that the clipboard is visually broken, which can be confusing for users when the content copied cannot be displayed in the clipboard entry. Ideally, the clipboard should be rejecting copy entries where there isn't any meaningful data, and when copies do have data that cannot be shown in the history, there should be a graphic or other visual to denote that there is data rather than leaving an empty list item. |
Created attachment 185697 [details] 2 images side by side depicting both issues described above, one showing a valid copy appearing as an empty clipboard entry, and an empty clipboard entry not appearing at all SUMMARY When copying to the clipboard, some applications may only supply metadata i;e chromium/x-.... and no actual paste-able data, leading to the current, empty clipboard entry not appearing in the history. This also causes these menus to break where clicking on the top entry in the list (which is technically below the invisible clipboard entry) to do nothing. STEPS TO REPRODUCE 1. Hit ctrl-c without selecting text in an application such as Discord (I was able to reproduce this with Vesktop) OBSERVED RESULT The clipboard history hasn't changed, but the clipboard content in the kwin debug console has changed to show a basically empty entry with just metadata on the application. Pasting in this state should also do nothing since the top entry logged by kwin has no data in it. EXPECTED RESULT Plasma ignores the empty copy since the application didn't actually send in a complete clipboard object. There are related issues to this where the clipboard history shows an empty box when there isn't a good way to represent the content, like when copying an image in a google doc (kwin shows html content in the clipboard but there are also a bunch of plaintext mime types that are empty, the clipboard should have a fallback to avoid displaying an empty box). SOFTWARE/OS VERSIONS Operating System: NixOS 25.11 (unstable) KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 Kernel Version: 6.17.1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: AMD Radeon RX 7800 XT ADDITIONAL INFORMATION I've attached an image showing both cases of mangled clipboard states, one where copying an image in a google doc correctly copies the content, but it creates an empty entry in the clipboard menu. The other image (right) shows the results of hitting ctrl-c in Vesktop without selecting anything, resulting in the clipboard history not showing a new entry at all, and the kwin debugger showing that there is an entry, just with no data. Sorry about the image quality, spectacle doesn't seem to work for internal windows.