SUMMARY When copying an object in Inkscape, Klipper requests the clipboard content in a large number of unnecessary mime types. Generating the extra formats makes copying noticeably slow and bloats clipboard history size. This is a follow-up to https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5315 https://gitlab.com/inkscape/inkscape/-/issues/5528 STEPS TO REPRODUCE 1. Open Inkscape and observe calls to ClipboardManagerImpl::_onGet(). 2. Draw a Rectangle. 3. Copy. OBSERVED RESULT The following mime types are requested: text/plain text/plain image/png text/plain text/plain image/png text/xml+fxg text/html text/x-tex text/xml+xaml text/x-povray-script EXPECTED RESULT Only image/svg+xml should be requested. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Graphics Platform: X11 ADDITIONAL INFORMATION The assessment at https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5315#note_1164002: > Some MIME types like image/svg from Inkscape could cause it to hang because > accessing data of the type means Inkscape will have to export the copied elements, > and if there are many elements, it will explode. is wrong; Inkscape does not explode because it is exporting too many elements (otherwise how would copy/paste have ever worked?), it is because Klipper is requesting export in every single advertised format - essentially a denial-of-service. Inkscape advertises a large list of mime types to provide interoperability with programs that only understand those formats. The intent is definitely not that they should all be copied. Only image/svg+xml needs to be copied in order to preserve the clipboard content losslessly, as all other formats are derived from that by exporting. The latest fix (!5315) only reduced the list of requested formats; it is is still sufficiently long to make copying take a second. It also appears to contain duplicates, for some reason.
Totally agree. For this to have a purpose with xdg-mime, it needs to be AT LEAST assuming: > text/* types as well as their > application/* counterparts > x-ruby > x-shellscript > x-python3 To be actual pasteable, copyable text and NOT just > text/plain Relying on xdg-mime and its returned filetype breaks copying into klipper from almost any applications: https://github.com/tmux-plugins/tmux-yank/pull/189 and to me its pretty clear that this is primarily upstream problem for the most part since it assumes so badly about all special chars. In tmux-yank's case its safe to assume as it factually text copied from terminal. Terrible workaround - which isn't very logic: > Configure > General Configuration > Non-text-selection: Never save in history Actually means 'Do not use xdg-mime' - because it still stores copied files from Dolphin in the clipboard (oddly despite what is documented above). A side-effect is also: > Configure > Action Menu > Show action popup menu: Immediately on selection and a configured shortcut: > Configure > Shortcuts Configuration > plasmashell > Manually Invoke Action on Current Clipboard Will not trigger when a different type is detected (which is totally random based on single special characters and far too uncertain)
> Terrible workaround - which isn't very logic: > > Configure > General Configuration > Non-text-selection: Never save in history I retract that statement. It worked at the time, now its reversed. I will have to look more into the code.
(In reply to dezzadk from comment #2) > > Terrible workaround - which isn't very logic: > > > Configure > General Configuration > Non-text-selection: Never save in history > I retract that statement. It worked at the time, now its reversed. I will > have to look more into the code. With both settings klipper seems to go into a state where it assumes the next copied text is of the same mime-type is all I can infer from it. Copying from vim with wayland support now randomly works - because it does not send a mime-type with it - exactly same issue as tmux-yank - so klippers functionality of auto-detecting via xdg-mime completely prevents normal clipboard operation.
Let me add a third program affected in addition to Inkscape and Libreoffice: LyX. Upon copying an equation, LyX hangs in lyx::cap::copySelection while consuming all available RAM, eventually crashing with a std::bad_alloc. During this time plasmashell is also frozen. I have verified that this behaviour does not happen on GNOME with the same LyX version. We've now had to put in a hack in Inkscape specifically to work around this behaviour: https://gitlab.com/inkscape/inkscape/-/merge_requests/7252. It's still not as good as an upstream fix though, especially for the duplicate requests.