User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Steps to reproduce: Copy an 8 bit image to clipboard (256 color bitmap). You can use IRFanview to decrease color depth to 8bpp if you need a sample. Then copy that image and paste in into a new Thunderbird message. Actual results: Shows a blank black box of the copied image. Expected results: Pasted fine in all versions up to 16.0.2 just fine. Reproducible on XP, Vista, and 7 everytime with version 17.0, but works fine in older versions.

Autsch! Gruesome. Confirming exactly as reported. Works perfect in TB2 (and up to TB 16 per comment 0), very broken in TB17. I'm not seeing a blank black box, but a distorted pixelish image with dark-grey background instead of white background. Strangely, inserting the same 8bit image using TB's insert > image (instead of copy/paste from IrfanView) works fine in TB17.

Insert > Image works differently as is just takes the image file "as is" and attaches it to the message. In contrast, copy-pasting an image involves recoding of that image from whatever is on the clipboard (usually a BMP-like format on Windows) into PNG or JPEG based on the desired target format. Do you see any difference depending on the setting of clipboard.paste_image_type, toggling it from "1" for PNG to "0" for JPEG? If it works with lossy compression, this may indicate a problem with the JPEG encoder; if it's the same for both settings, it's likely more an issue of grabbing the image pixels off the clipboard (or, potentially, how IrfanView puts the image onto the clipboard in the first place).

(In reply to rsx11m from comment #2) > If it works with lossy compression, this may indicate a problem with the JPEG encoder; I meant the PNG encoder, of course. I've just tried to reproduce with GIMP from a GIF image, but didn't see the effect on either Windows 7 or Linux (but an 8-bit image may not end up as such on the clipboard, I'd need to verify that).

test gif

This seems to only happen when I copy the image from an application such as Paint Shop Pro. If the same image is copied using windows explorer, it seems to paste fine.(and retains the gif format) Thomas..what is that clipboard viewer that you use. I don't have it installed on this PC

It is not just paint programs. I originally found it using TN5250 for windows and copying and pasting a screen for an email. I am sure it is a windows clipboard > thunderbird problem with 8 bit images.

This does work as a workaround. (In reply to rsx11m from comment #2) > Insert > Image works differently as is just takes the image file "as is" and > attaches it to the message. In contrast, copy-pasting an image involves > recoding of that image from whatever is on the clipboard (usually a BMP-like > format on Windows) into PNG or JPEG based on the desired target format. > > Do you see any difference depending on the setting of > clipboard.paste_image_type, toggling it from "1" for PNG to "0" for JPEG? If > it works with lossy compression, this may indicate a problem with the JPEG > encoder; if it's the same for both settings, it's likely more an issue of > grabbing the image pixels off the clipboard (or, potentially, how IrfanView > puts the image onto the clipboard in the first place).

Thanks, adjusting bug summary respectively. Glenn (I have you in mind as the expert on the image libraries used by Mozilla applications), are you aware of any change in the PNG library which may have caused or exposed this issue?

Hmm, according to bug 771394 libpng was updated to 1.5.11 effective with Gecko 16.0, then per bug 795662 to 1.5.13 effective with 18.0 (the 1.5.12 update was skipped). Thus, nothing from that end which would coincide with Gecko 17.0 and thus suggest a regression.

Good data from TB16 and bad data from current trunk.

Joe, since are able to reproduce it, can you figure out the regression range?

(In reply to rsx11m from comment #11) > Joe, since are able to reproduce it, can you figure out the regression range? Yes, a bit confusing tracing it back through the channels. So far it fails for me as far back as 20120803. I'm really expecting this to be a core Gecko issue. We'll see when I continue tonight.

Regression window Good: http://hg.mozilla.org/mozilla-central/rev/99c53832abfe http://hg.mozilla.org/comm-central/rev/9fbaed739443 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 ID:20120731031044 Bad: http://hg.mozilla.org/mozilla-central/rev/f6daa7cc4dd9 http://hg.mozilla.org/comm-central/rev/54f3c239ef7a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 ID:20120801030520 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=99c53832abfe&tochange=f6daa7cc4dd9 http://hg.mozilla.org/comm-central/pushloghtml?fromchange=9fbaed739443&tochange=54f3c239ef7a Suspected: Bug 460969

This also happens in Nightly20.0a2 http://hg.mozilla.org/mozilla-central/rev/253009438c5b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121203 Firefox/20.0 ID:20121203030801 Steps to reproduce: 1. Start Nightly20.0a2 2. Open http://www-archive.mozilla.org/editor/midasdemo/ 3. Start paint.exe 4. Open attachment 687335 [details] 5. Select All and Copy 6. Paste it into Textarea of Step2 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/a1db720c9c36 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120731035237 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/4fa21b477540 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120731051939 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a1db720c9c36&tochange=4fa21b477540 Suspected: Bug 460969

(In reply to rsx11m from comment #8) > Thanks, adjusting bug summary respectively. > > are you aware of any change in the PNG library which > may have caused or exposed this issue? There was a change in the libpng function that strips the opaque alpha channel, but we don't use that function. Instead we use our own StripAlpha function within our PNG encoder. Nothing else in the libpng-1.5-11 to 1.5.13 update looks suspicious to me.

Eddy - can you take a look at this this week, for possible resolution in the FF18 timeframe? This isn't a severe enough issue to track for release, but we would take a low risk uplift if found.

(In reply to Alex Keybl [:akeybl] from comment #16) > Eddy - can you take a look at this this week, for possible resolution in the > FF18 timeframe? This isn't a severe enough issue to track for release, but > we would take a low risk uplift if found. I can take a look at it, but my todo stack for this week is already quite full, so I can't promise it will happen this week.

Ew. If I'm reading this right, we don't use imagelib to decode clipboard DIBs into raw data. Trying to hack the image data out of a DIB like this is a losing battle. Could we not use something like imgTools::DecodeImageData?

(In reply to Matt from comment #6) > It is not just paint programs. I originally found it using TN5250 for > windows and copying and pasting a screen for an email. I am sure it is a > windows clipboard > thunderbird problem with 8 bit images. I too have the problem (https://bugzilla.mozilla.org/show_bug.cgi?id=825093). If I have a 24 bit image in a graphics program, then reduce the color depth to 8 bits, then copy, then paste into TB v17 I get: IrfanView 4.35 (Image > Decrease color depth > 256 colors). Image pastes corrupted FastStone Image Viewer 4.6 (Colors > Reduce colors > 256 colors). Image pastes OK GIMP 2.8.2 (Image > Mode > Indexed > Generate optimum palette > 256 colors). Image pastes OK IrfanView worked OK in previous versions.

Other symptoms appear to include problems when copying in-line images out of saved TB emails. The behaviour is different depending on whether the email is not opened; is opened for reading; or is being forwarded. The behaviour goes back a long time. Historically, I invariably paste images into TB and do not Insert > Image. An email created in June 2012 with TB 12.0.1 has an in-line image (probably pasted into TB) which I copy by: a) email closed. r-click image > Copy image > paste into app >>> OK b) email opened for reading. r-click image > Copy image > paste into app >>> OK c) forward email. r-click image > Copy (note different menu) > paste into app >>> fails Greyscale images paste into TB v17 OK, and copy out of TB, OK. Paradoxically, I believe I use a workaround that if I cannot copy an image (photo??) from a TB email, I forward the email, which makes the image available while it is being edited. I think r-click > Save Image As always works when offered (and saves as a PNG file). Also, when pasting an 8 bit image from IrfanView into TB fails, pasting it into another application (eg OpenOffice) succeeds, suggesting it is not (wholly) an IrfanView problem. 24 bit image > greyscale pastes OK from IrfanView into TB, but 24 bit image > 8 bit corrupts colors. (In reply to Joe Sabash from comment #5) > Thomas..what is that clipboard viewer that you use. I don't have it installed on this PC I use ClipBook Viewer to display what is currently on the Windows clipboard. When a copy out of TB fails, ClipBook Viewer says "Cannot display the information in its current format" and IrfanView says "Can't paste image from clipboard".

I would like to re-iterate this is not a problem with iRfanview. I actually have the problem with tn5250, and Attachmate Reflections, which are both green screen AS400 programs. Trying to do a screen capture and pasting into thunderbird is a real problem now, and never has been prior to version 17.0. I only used irfanview and a method to prove the 8-bit nature of the problem. Also, the work around I previously thought worked, does not seem to work any longer, the problem still persists currently.

(In reply to John_Ha from comment #21) > An email created in June 2012 with TB 12.0.1 has an in-line image (probably > pasted into TB) which I copy by: > a) email closed. r-click image > Copy image > paste into app >>> OK > b) email opened for reading. r-click image > Copy image > paste into app >>> > OK > c) forward email. r-click image > Copy (note different menu) > paste into > app >>> fails These are different issues and possibly covered by other bugs (if not, please file new bug reports). Content is copied onto the clipboard in various "flavors" as can be seen in a clipboard viewer, and the pasting application is picking the one it likes best. Many issues occur by, e.g., choosing the HTML version over the raw pixel data and the image referred to cannot be correctly extracted for some reason. Let's focus on the issue of pasting clipboard data from other applications as PNG images (with or without transparency) resulting from an incomplete bug 460969.

rsx11m, thanks for linking up to gs. Pls remember our convention to set bug URL to the gs TAG link rather than individual gs reports, so that all gs reports tagged with the bug no can be found.