I think in a year like 2019, it is a good idea to pick this up again, as Firefox is the only modern browser left with this behavior and copy/pasting, especially transparent, images is a convenient part of everyday browsing.

This is the simple repro page I created, right-click -> Copy Image and ctrl+V it back onto the page to see how the background becomes black.

If I right-click > Copy Image on a PNG with transparency and then paste into Windows 10 Paint 3D, the transparency is preserved. However, this is not true when pasting into a website (for example, Twitter). If we assume the data on the clipboard is correct, what needs to be done to preserve transparency when accessing a file from a ClipboardEvent.clipboardData (DataTransfer) object?

I'm so sorry to needinfo you, but is this under the wrong component? If 1520656 was under ImageLib then should this component be there as well? I don't seem to be able to change the component myself.

Thanks, vaindil. I am not sure of this but asking the person who filed this bug if it should be moved.

:jimm, this still a Widget::Win 32 issue or should it move to ImageLib?

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #47)

Thanks, vaindil. I am not sure of this but asking the person who filed this bug if it should be moved.

:jimm, this still a Widget::Win 32 issue or should it move to ImageLib?

This feels like a clipboard bug down in widget. I'll see if I can get someone to take a look.

Visualization of image transparency differs between Google Chrome and Firefox:
https://www.rgk4it.com/wp-content/uploads/2019/08/logo.png

Is it related to the way of firefox do image render?

This feels like a clipboard bug down in widget. I'll see if I can get someone to take a look.

Relevant Stackoverflow
https://stackoverflow.com/questions/44177115/copying-from-and-to-clipboard-loses-image-transparency

Windows clipboard transparency is a mess.

I intend to investigate this further along with the other image clipboard / color management work in the meta bug.

I am still experiencing this on Windows in Firefox 93.

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 10 votes.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

As a web-based graphic designer this bug is crippling and the reason why I keep going back to Chrome :(

Yeah we should fix this.

Back when this was filed, we used a completely different way to encode BMPs for the clipboard. Since bug 1501482, we now use our standard BMP image encoder. That should properly support transparency.

I suspect part of this is we don't request v5 of BMP images when we drag/drop:
https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/widget/windows/nsDataObj.cpp#1622

That can probably just be changed and improve things. Probably we don't ever want to provide v3 version here too:
https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/widget/windows/nsDataObj.cpp#994

I'm happy to attempt to fix this if you don't have time. I'm glad we already have v5 DIB code as that makes this kind of trivial.

It looks like we can/should also write PNG data to the clipboard: https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=726;drc=d030a17ad0ce961375e5e8d47cdc3e570b5a8fab

(In reply to Jeff Muizelaar [:jrmuizel] from comment #64)

It looks like we can/should also write PNG data to the clipboard: https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=726;drc=d030a17ad0ce961375e5e8d47cdc3e570b5a8fab

Yeah that would be a big improvement, see bug 1717306.

For bug 1717306 I would be interested in some Windows applications that currently have problems when copying images from/to Firefox and are free to install.

I'm working on this bug, my understanding is that we want to:

• setting clipboard - make Firefox offer PNG and BMPv5 on the clipboard, possibly also BMPv1 if any apps fail to use BMPv5.
• getting clipboard - make Firefox load PNG and BMPv5 on the clipboard with transparency support.

Current status I gather from this bug and the links on it and my browsing of the code:

• setting clipboard:
  • currently Firefox offers BMPv3 on the clipboard, the alpha channel is technically written but ignored by apps loading BMPv3.
  • currently Firefox does not offer PNG on the clipboard, which is required by some apps.
• getting clipboard:
  • currently Firefox loading BMPv5 does respect the alpha channel (?) according to some of the reports (e.g. copying in Chrome and pasting in Firefox).
  • currently Firefox does not attempt to load PNG from the clipboard (?) or does not respect transparency on it (?).

I'm going to test with a few apps to get a better idea of the current status of these assumptions, and verify if changes fix them. I'll post my findings as comments.

As a first test, I changed the code to offer BMPv5 instead of BMPv3 on the clipboard, and using chrome://branding/content/about-logo.png as a test image for copying with the context menu 'Copy Image' option, I tried pasting into the following:

• GIMP - pastes with transparency (correct), so GIMP appears to be optimistic about transparent imagery in BMP formats.
• LibreOffice Writer - pastes as opaque (incorrect)
• Google Docs in Firefox - pastes as opaque (incorrect), this is a problem with Firefox loading from the clipboard.
• Google Docs in Edge - pastes as transparent (correct)
• Windows clipboard browser (Win-V shortcut) - can't tell either way, always previews images as opaque, not a useful tool for testing.

So I don't think there is currently any problem with how Firefox posts BMP to the clipboard, but some apps need PNG.

I'll look into why Firefox is ignoring the alpha channel on load now (the Google Docs in Firefox case).

Debugging the clipboard code, we're correctly reading the BMPv5 from the clipboard as transparent, but then encoding it as a PNG to deliver to Google Docs, and that encoding of the PNG has the transparent flag set and all, but if I dump the memory to disk using WinDbg .memdump I get an image that when loaded in GIMP says it is RGB color. So there's something going wrong with creating the PNG image internally.

This is the invocation of the nsPNGEncoder https://searchfox.org/mozilla-central/rev/a44deb21744de6269329b05461c55488a147f95e/widget/windows/nsClipboard.cpp#730 and I'm not sure there is anything wrong with the options we're passing (useTransparency is on by default in the nsPNGEncoder code https://searchfox.org/mozilla-central/rev/a44deb21744de6269329b05461c55488a147f95e/image/encoders/png/nsPNGEncoder.cpp#90 ).

Looking at the mPNGInfo struct in the debugger:

width 192
height 192
valid 0
rowbytes 768
palette NULL
num_palette 0
num_Trans 0
bit_depth 8
color_type 6  (this represents COLOR and ALPHA flags)
compression_type 0
filter_type 0
interlace_type 0
channels 4
pixel_depth 32
...
trans_alpha 0
trans_color (all zeros)
...

I'm not quite familiar enough with the PNG format to see what is wrong with this mPNGInfo but I am guessing we're not quite correctly flagging it as transparent.

currently Firefox offers BMPv3 on the clipboard, the alpha channel is technically written but ignored by apps loading BMPv3.

I am a bit confused, because I was pretty sure that Firefox writes BMPv5 and BMPv3 to the clipboard. https://searchfox.org/mozilla-central/rev/a44deb21744de6269329b05461c55488a147f95e/widget/windows/nsClipboard.cpp#258-263

Thanks, yeah I found the BMPv5 code when I actually debugged it. The codebase has a lot of BMP writers and I found two that were not the relevant ones in my initial research but the debugger hit the right ones :)

So in further debugging/editing, I've managed to get the nsBMPDecoder to cooperate with transparent BMP on the clipboard, at least from some apps (including Firefox), so I can freely copy from Firefox to Firefox, from Firefox to GIMP, from Firefox to Edge, but not GIMP to Firefox which seems to have something meaningfully different about the BMP data it posts on the clipboard, whereas GIMP to Edge works fine, so there's something I don't understand yet about how GIMP's clipboard objects work.

In my local repo I have several fixes coded, and will be sending the stack of diffs out for code review next week.

Status:

• Copying to clipboard now posts as the format identifier ::RegisterClipboardFormatW(L"PNG") (which seems not entirely successful - still debugging our internal format conversions which is skipping over this) and CF_DIBV5 and CF_DIB, now the CF_DIBV5 is posted with Compression::BITFIELDS which works well for some apps (including Firefox) that understand this more advanced format which gives us a better opportunity to hint there is intentionally an alpha channel in the image (which Firefox already understood), the CF_DIB is still Compression::RGB for best compatibility (but apps reading this will almost always drop the alpha channel).
• Pasting from clipboard now attempts to handle ::RegisterClipboardFormatW(L"PNG") and CF_DIBV5 and CF_DIB, both CF_DIBV5 and CF_DIB with Compression::RGB are interpeted with an assumption the alpha channel is valid, this could theoretically break but I have yet to see an app post garbage in the alpha channel so it most likely works broadly, it treats images that are entirely 0 alpha as entirely opaque for broadest compatibility (same logic we use when reading DIB images in ICO files).
• Dragging an image from Firefox writes the file as BMPV5 with Compression::BITFIELDS working for drag and drop (this is where it gets more peculiar as BMPV5 with BITFIELDS is a relatively newer and more advanced format, but it's our only opportunity to clearly hint that the alpha channel exists using BMP format), it would likely be better to write the file as PNG as BMP so I'll be trying to get that working too.
• Dragging an image into Firefox already works with multiple formats, so not much to do there.

Since I've been adding PNG support (both copying and pasting) I've added Bug 1717306 as a dependency as my patches will likely resolve that as well.

Ashley, are you still working on this? "will be sending the stack of diffs out for code review next week" was a while ago ;-)

I'm aiming to land the majority of the code I wrote in https://phabricator.services.mozilla.com/D164531 this week, but I need to remove the pref clipboard.copy_image_as_png_format as it isn't working.

My progress on this bug has been blocked on an issue with the code for the new pref clipboard.copy_image_as_png_format - we have a rather arcane set of internal abstractions for interacting with the clipboard, and despite registering a png data callback it never gets called, so the pref doesn't work, and it's key to resolving this bug, but I do have a number of other fixes and improvements pending in that diff so I will try to land them.

My current plan for the code in the diff is to:

• Split out the pref clipboard.copy_image_as_png_format and associated code into its own bug and diff.
• Change the pref definitions to enable by default in nightly for:
  • clipboard.paste_image_support_bmp_transparency_with_rgb_compression
  • clipboard.copy_image_as_bmpv5_using_bitfields_compression
  • clipboard.drag_and_drop_images_as_png
• Keeping the default-off setting for pref clipboard.drag_and_drop_images_as_bmpv5_using_bitfields_compression, but the code will be there. This pref causes our drag and drop image posting to be bmpv5 with bitfields compression - it's likely that a lot of apps would not understand this format, and it's arguably better to use png (hence that pref being on by default instead).

It feels bad to land it without clipboard.copy_image_as_png_format but until I get more help debugging that I can't really proceed on that fix.

I got the PNG copy/paste to work so I'll be trying to land https://phabricator.services.mozilla.com/D177868 before fussing more about bmp handling as it mostly or completely resolves this bug.