User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Run the example code on MDN (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/clipboard/setImageData) for any transparent PNG file on a Windows machine and paste the image to Office, LibreOffice or the like.

Actual results:

The transparency of the image is turned to black.

Expected results:

The transparency shouldn't be lost.
It works when copying the image via right click > copy image.
The browser.clipboard.setImageData also works on Linux as expected.

Tested this on Windows 10 64-bit with Ff Release 69.0 (20190827005903), Ff Beta 70.0b6 (20190912160217), Ff 71.0a1 (20190917093629).
With the code for copying a remote image , taken from the suggested MDN web docs, I've created the attached "clipboard-copy" extension which makes use of a transparent background image which has been opened separately in a different window.
After loading the extension in about:debugging I was able to paste the image in a LibraOffice document and indeed the background turned black BUT I noticed that this is also something that occurs when using the image url from the extension in a browser new tab.
It seems to me that when opened in a different tab the online transparent background image loses that transparency so it would make sense to have a colored background when pasting it onto a document.
Or perhaps I am missing something. Could you provide a test extension which indeed makes use of a transparent layer image to be able to verify this?
On another note, I did not make use of the 'https://cdn.mdn.mozilla.net/static/img/favicon144.png' url due to it directing to a 404 bad request.

I'm not sure if I understand you correctly, but I guess by

the online transparent background image loses that transparency

you refer to the grayish background an image gets when opened in a new tab?

If so, than this cannot be the cause. The background color one can see when opening a transparent image in an new tab is defined by the User Agent CSS (you can see it when opening the inspector)

img.transparent { background: hsl(0,0%,90%) ... }

If you were talking about something else then I don't know what you mean and need some further explanation.

Or perhaps I am missing something. Could you provide a test extension which indeed makes use of a transparent layer image to be able to verify this?

Your test-extension provides a perfect example of the problem.

When I was trying to reproduce this issue yesterday, when I opened the PNG url in a new browser tab, it also gained a black background. Since it looked like I was pasting into the Libre Office document I used for tests, an image with an already colored black background, the bug validity was in question.
In any case I could not reproduce that today when testing on Windows and I when opened the image in a new browser tab it retained that greyish background color and when pasting it with the use of the extension into a white or colored document, it produced a black background.
This occurs on Windows 10 64-bit with latest FF Release 69.0 Ff (20190827005903), Beta 70.0b7 (20190916074538), Ff 71.0a1 (20190917155453). See attached "Image Background transparency is lost when pasted using extension.gif"
When testing on Ubuntu 18.04.3 LTS and MACos High Sierra 10.13.6 the pasted PNG transparency is retained. Attached "Ubuntu PNG transparency" GIF.

I am not sure if PNG with transparency can even work in Windows. The code in nsDataObj::GetDib converts the PNG to BMP, which does not support transparency AFAIK. Not sure who is really responsible for this code.

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

I am not sure if PNG with transparency can even work in Windows. The code in nsDataObj::GetDib converts the PNG to BMP, which does not support transparency AFAIK. Not sure who is really responsible for this code.

As written in comment #0, "right click > copy image" preserves the transparency. So it should have a way to preserve transparency on paste.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

I don't know enough about the underlying code, but is this really a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=460969 ?

Since the following does not apply to this bug:

If I right-click > Copy Image on a PNG with transparency and then paste into Windows 10 Paint 3D, the transparency is preserved.