When dragging an image in the same tab we produce a application/x-moz-nativeimage data item that contains an imgIContainer. However when dragging the same image across tabs/window (i.e. across content processes) we seem to "serialize" that data into a string and get absolute garbage.

Steps to reproduce:

• Open https://evercoder.github.io/clipboard-inspector/
• Open some new window with e.g. https://i.imgur.com/H3y8CxA.jpeg
• Drag the image in the inspector.

(Interestingly enough dragging the image across two different instances of Firefox actually works better, because we save the image to the native "drag service")

On Linux, when dragging across instances of Firefox, I don't get image data at all. When dragging within an instance, application/x-moz-nativeimage indeed looks like garbage.

Mirko, can you, please, take a look?

So this happens because in the parent we call TransferablesToIPCTransferables in ContentParent::MaybeInvokeDragSession. TransferableToIPCTransferable will convert the imgIContainer used as data for application/x-moz-nativeimage to shmem.

In the child ContentChild::RecvInvokeDragSession we see IPCDataTransferData::TShmem and convert that to a simple string. This obviously isn't the correct behavior. We should actually use nsContentUtils::DataTransferItemToImage like IPCTransferableToTransferable does. Probably the correct fix here would be to to unify more of this code.

On Linux, when dragging across instances of Firefox, I don't get image data at all.

bug 1732528 and bug 1732526 should fix that. It should already work on Windows.

This does leave us in the somewhat weird situation where dragging images across different Firefox instances will work, but not in the same tab ...

I wonder if this only affects Linux.

I can reproduce this on a Windows VM. In the screenshot you can see two windows of the same Firefox instance. I dragged the image on the right to the clipboard inspector on the left.

Hello! I can reproduce the issue with Firefox 94.0a1, 93.0b9, 92.0.1, 91.1.0esr and 78.14.0esr. This happens on macOS 10.15 and Windows 10x64.
Also I searched for a regression range on Windows 10x64:
Last good revision: 5a4412474c63e1d9e66036d603ac42e9cb2b9150 (2017-01-23)
First bad revision: 8ff550409e1d1f8b54f6f7f115545dbef857be0b (2017-01-24)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5a4412474c63e1d9e66036d603ac42e9cb2b9150&tochange=8ff550409e1d1f8b54f6f7f115545dbef857be0b

Changing severity to S2 because non-minor functionality is impaired and no satisfactory workaround exists.

This is a copy of the similar code in RemoteDragStartData::AddInitialDnDDataTo

This patch "hides" the garbage from content JS, because we don't expose imgIContainer. However we really should expose some way to get the actual image data in a sane format like image/png.

(In reply to Tom Schuster [:evilpie] from comment #8)

This patch "hides" the garbage from content JS, because we don't expose imgIContainer. However we really should expose some way to get the actual image data in a sane format like image/png.

FWIW chrome also won't expose the raw image/png if you drag & drop an <img> tag into a drop area, it'll only expose 3 items: text/plain, text/uri-list and text/html, so this behaviour may be intentional. This is also the case if you drag an image from firefox into chrome or between two firefox instances.

FWIW chrome also won't expose the raw image/png if you drag & drop an <img> tag into a drop area, it'll only expose 3 items: text/plain, text/uri-list and text/html

Yeah, I noticed that as well. I wonder if that is intentional.

On windows dragging images from Firefox to Edge works, but not Edge to Firefox. Between two Firefox instances (different profiles) also works. However the default format of native clipboard data on Windows is BMP and not PNG.

https://hg.mozilla.org/mozilla-central/rev/93d9318f78d7

Confirmed issue with 94.0a1 (2021-09-23), on Win10.
Fix verified with 94.0b2 on Win10 and Ubuntu 16x32.

Based on Comment 13, I'm marking this issue as Verified Fixed.