Can't pipe large images into xclip while CopyQ is running

[CyberShadow]

If I run the command:

xclip -selection clipboard -in -target image/png < scr.png

where scr.png is a large image (3840x2160), while CopyQ with the "Images" item format enabled is running, then, after a few seconds, the following is printed in the terminal:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x1200006
  Serial number of failed request:  38
  Current serial number in output stream:  38

xclip thus crashes, making the image unavailable to other applications. The image does not reach CopyQ's clipboard history (even when increasing the "Maximum Image Width/Height" options past the image size).

[hluk]

Is this issue in last version? What's output of copyq --version?

There were few fixes in latest release to handle big clipboard data. I have no problems copying 300MiB image with xclip (thought it takes few seconds until it shows up in CopyQ).

[CyberShadow]

Oops, I'm still on v3.7.1. Will retest once on 3.7.2.

[CyberShadow]

Hi, I'm still seeing this on 3.7.3. The problem occurs even with the Images plugin disabled. I must have gotten confused when reporting this, because restarting CopyQ makes the problem go away. Exiting CopyQ also allows xclip to work properly.

[hluk]

I still cannot reproduce this in v3.8.0. Maybe an automatic command in CopyQ is interfering somehow.

[hluk]

OK, I can occasionally reproduce the error.

...
> xclip -selection clipboard -in -target image/bmp < Untitled.bmp
> xclip -selection clipboard -in -target image/png < Untitled.png
> xclip -selection clipboard -in -target image/bmp < Untitled.bmp
> X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x4800005
  Serial number of failed request:  1552
  Current serial number in output stream:  1552

Looks similar to #636. Probably partially problem in how Qt retrieves data but I don't see how it can crash foreign app just by requesting clipboard unless there is a bug in that app itself (or in an library it uses, XCB, X11).

[H8to]

I also sometimes experience the same issue, but totally random. Sometimes it copies the image successfully. I have been using the function a while ago in a custom Nemo plugin to copy image files to clipboard but now it does not work reliable any more in conjunction with copyq.

[ghost]

Is there a way to force CopyQ to ignore images? It's crashing Gimp for me as well as others https://gitlab.gnome.org/GNOME/gimp/issues/2733 I still want to use it, just not with images.

[hluk]

Is there a way to force CopyQ to ignore images?

@mastahcez Just disable "Images" in "Items" configuration tab. It's mentioned in FAQ: https://copyq.readthedocs.io/en/latest/faq.html#how-to-store-only-plain-text

[ghost]

Thanks, I tried that, it still crashes gimp with this option turned off.

[hluk]

Is this still an issue in new version? I did some improvements when fetching large clipboard data. There should be a warning in the log (F12 shortcut from main window) if accessing clipboard takes too long.

[CyberShadow]

Yes. With CopyQ v3.9.2, I still can't pipe a large image into xclip while CopyQ is running. Everything in Settings->Items is unchecked.

[CyberShadow]

I just noticed that having Kolourpaint open has the same effect as having CopyQ open. I'm guessing it is a problem with Qt after all. Having GIMP open is fine.

[hluk]

@CyberShadow I think it's issue in X11 which cannot handle large data safely.

Qt times out after 5 seconds when retrieving clipboard data (unfortunately the data cannot be retrieved asynchronously using the API Qt provides).

I would need to implement fetching clipboard using for X11. But now I'm even less tempted to do it since it seems that Wayland is going to take over (it's already enabled by default in Fedora).

[CyberShadow]

it seems that Wayland is going to take over

Wayland still has many challenges to overcome before it becomes mainstream in most Linux distributions. Many things that users expect to work are impossible by design in the Wayland protocol, e.g. Wine is unimplementable under pure Wayland.

[hluk]

I've tested couple of scripts and it seems that Qt is unable to access the clipboard.

I've also tested pasting in gvim (presumably uses Gtk) and it works.

Script to disable CopyQ momentarily and set random text to clipboard (100MiB):

#!/bin/bash
set -ex

copyq disable
trap "copyq enable" EXIT QUIT HUP INT TERM

xxd /dev/urandom | head -c 100M | xclip -selection clipboard -in -target text/plain
echo "Press Enter key..."
read

If you stop it by pressing Enter key, CopyQ will try and fail to get the new text.

Instead you can also try pasting to a Qt widget (requires PyQt5):

#!/usr/bin/env python3
import sys

from PyQt5 import QtWidgets

app = QtWidgets.QApplication(sys.argv)
edit = QtWidgets.QPlainTextEdit()
edit.setUndoRedoEnabled(False)
edit.setLineWrapMode(QtWidgets.QPlainTextEdit.NoWrap)
edit.show()
app.exec_()

Or start following script to wait for clipboard change, print the text (fails again) and exit (start the set-clipboard script after this is started).

#!/usr/bin/env python3
import sys

from PyQt5 import QtGui

app = QtGui.QGuiApplication(sys.argv)

def changed():
    print('clipboard changed')
    print(f'content: {app.clipboard().text()}')
    app.exit()

app.clipboard().changed.connect(changed)

print('waiting for clipboard change signal')
app.exec_()

[amerlyq]

Actually I noticed the same problem even for plain text around 3-5kB worth. I write Jira/Confluence markup in neovim and then copy-paste it into qutebrowser using xsel. Before text becomes "long enough" everything is copied OK. But otherwise almost each time (beside some happy occassions) I'm forced to shutdown copyq, copy-paste, and start copyq again. Tiring.

Maybe the problem is both qutebrowser and copyq are Qt-based, but who knows. This problem persist for last half of a year or even more and wasn't observed before that. But I can't precisely dedicate it to changes in copyq or Qt codebase.

[souravdas142]

gimp
The program 'gimp' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 102364 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

(script-fu:6019): LibGimpBase-WARNING **: 23:26:01.707: script-fu: gimp_wire_read(): error

The problem still exist System: Host: Arch-Linux Kernel: 5.5.10-arch1-1 x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: i3 4.18 Distro: Arch Linux

installed from Arch Repo. GNU Image Manipulation Program version 2.10.18 CopyQ Clipboard Manager v3.10.0 Qt: 5.14.1 Compiler: GCC Arch: x86_64-little_endian-lp64 OS: Arch Linux

if i disable image from item, the problem still exist until i exit copyq from system tray.

same issue with maim and rxvt-unicode

maim --format png | tee ./xyz.png | xclip -selection clipboard -t image/png

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x5600005
  Serial number of failed request:  25
  Current serial number in output stream:  25

@hluk

[stingray21]

same for me :(

Manjaro Linux (Gnome 3.36.0)

installed via pacman: GIMP 2.10.18-4 (extra repo) CopyQ v3.10.0-1 (community repo) Qt v5.14.1-1 (extra repo)

CopyQ with Images unchecked in Items

[rcrath]

ditto here. gimp 2.10, copyQ 3.10.

Workaround is to disable copyq clipboard from the copyq file menu.no gimp crash then.

It would be great, if the problem is upstream in qt, if copyq could be set to ignore gimp rather than filetypes.

[hluk]

The Qt bug is reported here: https://bugreports.qt.io/browse/QTBUG-56595

[SGmuwa]

In some cases, you can use text/uri-list instead of image/png.

echo "file:///path/to/image.png" | xclip -selection clipboard -t text/uri-list

But this does not allow copying the message from the pipe directly, however you can save the image from the pipe to tmp and then use the uri.

cat my-image.png > /tmp/img.png && echo "file:///tmp/img.png" | xclip -selection clipboard -t text/uri-list

It's works with Telegram Desktop for example.

[gabyx]

This is also a problem under wayland with sway and wl-copy -t image/png <large.png. Copyq will not add an entry, but with smaller images it works.