User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E) Note that I have not personally confirmed this bug, neither do I know how to easily do so. I have read about this bug on the Paint.NET blog: http://blog.getpaint.net/2010/11/10/paint-net-v3-5-6-lets-fix-a-few-more-bugs/ "For Firefox, it places a bitmap with the pixel format set to 32-bpp RGB (“no alpha”). However, it lies … so I detect when I should interpret it as 32-bit ARGB instead." I've looked around for bug reports on this, and couldn't find anything, so... Hopefully it's not a dupe. Reproducible: Always

I'll just copy and paste what the Paint.NET author said on the page I posted above: "Actually I guess it’s not so much that Firefox “lies”. It only places a CF_DIB onto the clipboard which is incapable of encoding alpha information. Once GDI+ gets its hands on it, it gives me a System.Drawing.Bitmap whose PixelFormat is PixelFormat.Format32bppRgb. A CF_DIBV5 can support alpha by setting the bV5AlphaMask, when the bitcount is 32. In either case, it’s still questionable whether this will work well, since the clipboard doesn’t always play nice when it comes to bitmaps that have alpha. For additional context, Google Chrome does put a CF_DIBV5 on the clipboard. But then of course it sets the alpha mask to zero instead of 0xff000000. Fun!"

Reporter -> Are you still experiencing this issue with the latest version of Firefox 5? Does the issue occur with the latest nightly? http://nightly.mozilla.org/

I never experienced this issue personally, I just filed it on behalf of the person who encountered it, as explained above.

Sigh. We probably need a bugzilla component for clipboard stuff. Core:Widget is probably close enough. Confirming based on blogger who sounds like he knows what he's talking about. :)

The code is a bit crufty, but if I remember correctly the interesting part of copying images ends up in http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsClipboard.cpp Specifically nsClipboard::SetupNativeDataObject() where it's doing image stuff. I'd be happy to help anyone who wants to take a shot at fixing this.

Actually the heavy lifting is done in nsImageToClipboard::CreateFromImage in http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsImageClipboard.cpp

dupe of bug 249032 which in turn is a dupe of bug 460969 (the latter one contains a patch)

As for comment 7 I'll set this as Duplicate