Issue 106549 - Cannot paste image from clipboard with GNOME clipboard manager
Summary: Cannot paste image from clipboard with GNOME clipboard manager
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.1.1
Hardware: Unknown Unix, all
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needhelp
Depends on:
Reported: 2009-11-02 11:53 UTC by m8t
Modified: 2014-02-02 13:01 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description m8t 2009-11-02 11:53:58 UTC
When I'm using the gnome clipboard manager (available in gnome-settings-daemon)
or the xfce4-clipman-plugin (which bundles the same daemon) and I copy an image
into the clipboard (f.e. with gnome-screenshot) it is possible to paste it
within writer/impress/... but it will hang for a while and finally nothing is

Without the daemon it works (but of course the application that puts the image
into the clipboard must not quit or the clipboard content will be lost). I
looked a bit around and perhaps OOo is miss-interpreting the XATOMS.

Without the daemon:

With the daemon the images gets stored with these:

Pasting the image into other programs like gimp works fine.
Comment 1 m8t 2009-11-02 12:58:56 UTC
Mmh, when I copy the screenshot to clipboard with gnome-screenshot everything is
fine (the XATOMS are kept intact), it is only when I copy the image to clipboard
with xfce4-screenshooter. Will have to digg a little more to make sure why both
screenshot apps are behaving differently.
Comment 2 m8t 2009-11-02 13:05:14 UTC
Ah... seems gnome-screenshot doesn't send a store even to the clipboard manager
so unless the application is not closed the XATOMS are like the ones I pasted
without the daemon, but once the application is closed it gets stored inside the
clipboard manager with different XATOMS.
Comment 3 m8t 2009-11-09 15:12:28 UTC
I think I found the bug, it comes definitely from the clipboard manager. Once
saved within the CM it reports the target image/bmp but that particular target
(amongst tiff, x-bmp and x-MS-bmp) is empty. In fact there is no format nor a
length reported for it.

When I try to get that target with a GTK+ test program it simply returns. Could
it be that OOo tries to read the first target and hangs in there (it hangs for
quite a few seconds)?
Comment 4 m8t 2009-11-09 17:21:19 UTC
Fact that it is hanging shows that the amount of data to get from the clipboard
is huge... probably way-way lot more than what it should be. And in the end the
bmp image is garbage.

I looked what OOo tries to paste first and it is indeed the image/bmp target
(the order is not important e.g. if it is first or last in the target list).
Gimp tries first the image/png target which has no problem and the reason why it
was actually able to paste anything at all.

My test program can be found here:

I opened a big png image and pass it for the image/bmp target (which is
obviously wrong) and I was able to reproduce the bug I discovered with the CM.

Gonna comment upstream on the CM about this fact.

I guess the bug can still be left open cause if OOo fails to load the image/bmp
it should try another target until there isn't anymore left. And I had like to
suggest to load image/png first as it has an alpha channel which doesn't exist
for bmp images!

Cheers :-)