Virtualbox bidirectional clipboard for images problem

[Rover]

Hello,

I have a Virtualbox Windows Host (ver 6.0.8) running on Windows 8.1 (64-bit) and I have several Linux Mint 19.1 (64-bit)s VMs. Each VM has Guest Additions installed.

I am having some odd behaviour when copying image from the host to the VM via the bidirectional clipboard. All VM has this enabled as well as bidirectional drag-drop. This problem only happens when image from host to guest as one can copy and paste textual materials to the guest with no problem. One can use the Clip command in Windows 8.x upwards like this:
dir | clip

to transfer text to clipboard.

Here are the steps that replicate the problem:
A1) In the Windows Host, I use the "Snipping Tool", the standard Windows tool, to capture an image and transfer to the clipboard. I use Windows LibreOffice (6.1.6.3) Writer to create a document and paste the image into it just to confirm the image is there. One could use WordPad too.

A2) When I paste this very image into a program in Linux, it turns out empty (using Linux Thunderbird message) or a black image (in LO Writer of the same version as the Windows).

To prove it is there and here are the steps to show and as a work around, do this:
B1) Fire up a graphic/image editing program like GIMP or Pinta, and paste from the clipboard. You can see the identical image produced by the "Snipping Tool" in the host. This shows the transfer is working. If not repeat step A1) above.

B2) Now copy the image from these graphic/image editing programs to the clipboard in the VM, and you can then safely paste that into any program that can handle images in the VM as well as those that failed in Step A2).

The converse has not problem. That is if you use a screen capture program in the VM like Shutter or Mint's screen capture to transfer the image to the clipboard, you can paste that safely in any host's programs that can accept images.

I do not have a non-Windows host to test if this oddity happens in other host type. Perhaps someone can test this and to verify my work.

I have run the same experiment using VMWare Workstation Player (12.5.9) for Windows host and using the same version of Mint as guest. No problem to and fro the guest is observed. It is therefore fair to say the problem lies with VirtualBox.

Has anyone encounter problem like this?

Thanks.

Rover

[socratis]

Images in the clipboard are really restricted in what format they can serve. In fact, looking through the sources at VBox/GuestHost/SharedClipboard/clipboard-common.cpp, you'll see that only the DIB/BMP format is supported. If your app puts the image in the clipboard in other formats, it won't work. See the comments from VBox/GuestHost/SharedClipboard/clipboard-x11.cpp for example:

{ "image/bmp", BMP, VBOX_SHARED_CLIPBOARD_FMT_BITMAP },
{ "image/x-bmp", BMP, VBOX_SHARED_CLIPBOARD_FMT_BITMAP },
{ "image/x-MS-bmp", BMP, VBOX_SHARED_CLIPBOARD_FMT_BITMAP }

/** @todo Inkscape exports image/png but not bmp... */

[Rover]

Hello,

Yes, you are correct. What I believe is when VBox detects the clipboard deposition from host and it then transfer that to its guest, VBox may have left out some format.

Why I said that is because I have tested using identical Windows program to capture the image (only the image content is different) and hence it must deposit the image to the clipboard with the same list of registered formats that that list is irrelevant to the existence of hypervisor. I also use the identical guest program as I used for other tests in the guest to ensure the consumption part is identical.

The bit in the middle is what changes and thus causing problem.

I use Snipping tool to VMWare Workstation Hypervisor and to LibreOffice Writer: no problem.

I use Snipping tool to VirtualBox Hypervisor and to LibreOffice Writer: cause problem.

The difference is that middle part. Inserting GIMP or Pinto to the process must have enrich the list of formats sufficiently allowing other programs to insert the image. It is also possible VBox uses a static list of formats rather than emulating the list of formats registered by the sender, the Snipping Tool in my case.

I will see if I can find out the list of formats registered by Snipping tool and then compare that with your list.

Thanks.

Rover

[socratis]

Check out the following:

• Free Clipboard Viewer,
• ClipView,
• InsideClipboard

I will see if I can find out the list of formats registered by Snipping tool and then compare that with your list.

It's not a list I'm afraid if it's a single option only; DIB/BMP.

[Rover]

Hello,

I used .Net's System.Windows.Clipboard.GetDataObject().GetFormats() to enumerate the list of formats registered on the Clipboard. When using Snipping tool to copying image and here is the list in Windows' parlance
System.Drawing.Bitmap
Bitmap
DeviceIndependentBitmap
Format17

I tried the same experiment but this time, the source program is MS Paint and I can paste that image into Mint's LO Writer. This time the formats registered are:
Embed Source
Object Descriptor
MetaFilePict
DeviceIndependentBitmap

From your discovery, It appears VBox can handle DIB as that is the common between Snipping Tool & MSPaint. The only conclusion I can draw on this is not the format per se but seems to be missing pieces in the image format (kind of incomplete encoding).

Here is the format when I paste the image from clipboard to Pinta and from Pinta back to the clipboard and the registered formats as observed in Windows:
DeviceIndependentBitmaap
System.Drawing.Bitmap
Bitmap
Format17

I clear the clipboard in between experiment.

I will do some more digging around. Wharever it is VMWare Workstation Player Host works flawlessly.

Rover

[socratis]

Wharever it is VMWare Workstation Player Host works flawlessly

I'm sorry, but what on earth does this have to do with the whole thing? Are you often comparing MSOffice and LibreOffice? This isn't a "feature" contest. VirtualBox supports certain things, other programs support others. C'est la vie...