User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Build Identifier: version 1.5.0.4 (20060516) Pasting a PNG copied from Firefox to the clipboard pastes as a JPEG, losing quality. Reproducible: Always Steps to Reproduce: 1. Find a PNG in Firefox 2. Right click and choose Copy Image 3. Paste into a Thunderbird Compose window 4. Observe the loss of quality 5. Send the email to yourself to verify Actual Results: As soon as the paste occurs, I can see that it has gone lossy. The email that is sent has Content-Type: image/jpeg; name="moz-screenshot-1.jpg" Expected Results: The image should show the same quality when pasted. The email sent should be image/png I presume that this is a bug in Thunderbird and not in Firefox as if I paste it to Paint there is no loss in quality visible.

Confirming based on bug 223909 comment 6 et seq. Also cmts 38 & 39 indicate that there is some significant change to this part of the program, altho nothing indicating whether the original image type will be maintained.

when you copy&paste in to another application we send the raw bits across -- not the PNG. That is why you don't see any loss. Thunderbird reencodes the raw bits to JPEG and sends them. Emailing the raw bits would suck a lot. This isn't really a bug.

(In reply to comment #2) > when you copy&paste in to another application we send the raw bits across -- > not the PNG. That is why you don't see any loss. Thunderbird reencodes the > raw bits to JPEG and sends them. Emailing the raw bits would suck a lot. This > isn't really a bug. > See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/dataexchange/clipboard/clipboardformats.asp# On Windows at least, an application that copies to the clipboard can specify that it is available in multiple formats. Firefox should be providing it as a raw bitmap and as a PNG. Thunderbird should prefer to paste the PNG. I note that PNG isn't in Microsoft's defined list of formats, but the API does allow for additional named formats to be added. I had assumed that Firefox was already doing this, but perhaps not. I think it is sensible for Thunderbird to paste a bitmap as a JPEG if no other format is available, as this is a sensible behaviour for email. Ideally it would run a heuristic to see if the image is more sensible as a PNG (just a count of the colours used would do as a start). Firefox needs to do its part and make the PNG available as a PNG to the clipboard. I don't know if it is doing so at the moment. I suspect that Firefix isn't doing this, but Thunderbird isn't capable of pasting a PNG either. Therefore I think this bug should remain open to get this functionality added. I suppose a separate bug needs to be opened for Firefox support if it doesn't have this support?

You could open a new bug on it.. I wouldn't expect it to get fixed any time soon though -- we don't have a good way to get back at the original non-decoded image data so putting something other than the raw bitmap data on the clipboard will be hard.

(In reply to comment #4) > You could open a new bug on it.. I wouldn't expect it to get fixed any time > soon though -- we don't have a good way to get back at the original non-decoded > image data so putting something other than the raw bitmap data on the clipboard > will be hard. > What about 'Save Image As'? That gets the original data (I assume from the cache).

A backend for this is being developed in bug 384116. Different platforms have different ways how the clipboard is implemented: (1) If the clipboard mechanism offers various flavors of image encodings (e.g., PNG or JPEG for Linux), the HTML editor can accept them. A patch has been approved in bug 384116 that allows to specify the order of preference for PNG, JPEG, or GIF formats, as available on the clipboard. (2) If the clipboard does not provide a suitable format (as appears to be the case with Windows), it has to be converted. Currently, only JPEG is offered. Another patch in bug 384116 would increase the encoding quality. Further work is yet necessary in the Windows widgets to encode the image in PNG or GIF as well, according to the user preference. (3) In terms of a frontend for Thunderbird, this could be covered here after the backend is finalized. For example, some dialog, menu item, or an extension of the preference pane to specify the preferred encoding flavor for pasted images. For the specific case of copy-pasting an image from Firefox into an e-mail created in Thunderbird, you can drag-and-drop the image from Firefox directly into the message body. This will copy the image location (Image Properties shows an http link) and attach the image as downloaded from the web site without any re-encoding necessary (thus no loss of quality).

A few updates: > (1) If the clipboard mechanism offers various flavors of image encodings (e.g., > PNG or JPEG for Linux), the HTML editor can accept them. A patch has been > approved in bug 384116 that allows to specify the order of preference for PNG, > JPEG, or GIF formats, as available on the clipboard. After the nightly builds switched to comm-central, pasting in PNG format should now be available on trunk for all platforms other than Windows. > (2) If the clipboard does not provide a suitable format (as appears to be the > case with Windows), it has to be converted. Currently, only JPEG is offered. This is now bug 444800. If other platforms need adjustments in their Widgets code, those should probably be filed as separate platform-specific bugs. > Another patch in bug 384116 would increase the encoding quality. Moved to bug 444898 and awaiting superreview there.

(In reply to bug 386952) > Something like CTRL+V to paste as jpeg and CTRL+(SHIFT/ALT)+V to paste as png. Related to (3) of comment #6 here. The default behavior is set by a preference according to bug 384116, which should cover most cases. For a specific choice, an additional "Paste As" function could be added (common in many applications), where a dialog pops up with a list of formats in which the clipboard content can be pasted. This would obviously require to extend the currently boolean nsHTMLEditor::CanPaste() function to return more specifically which flavors are currently available to chose from.

(In reply to comment #6) > (2) If the clipboard does not provide a suitable format (as appears to be the > case with Windows), it has to be converted. Currently, only JPEG is offered. > Another patch in bug 384116 would increase the encoding quality. Further work > is yet necessary in the Windows widgets to encode the image in PNG or GIF as > well, according to the user preference. I've been working on a related bug - bug 440911, which deals with drag and drop out of the content window. One of the things I noticed is that copy paste drops transparency data from png files copied out of the content area. I believe this is the reason why this bug was posted. Is that correct? The problem could probably be addressed by adding support for transparent bmp formats in our rendering and receiving code. For example, the data for a copy is rendered in nsImageToClipboard::CreateFromImage. The format we render to is an outdated version of the windows bitmap format. The receiving code appears to be in nsImageFromClipboard ::GetEncodedImageStream, which sufferes from the same problem. I'd be willing to bet we could address the transparency and other image quality problems by adding support for the newer (win95+) bitmap formats that support alpha, jpeg, and png compression. (http://msdn.microsoft.com/en-us/library/ms532331(VS.85).aspx) From what I understand, the patch in 444800 only addressed the situation where a target wanted to receive a png instead of a jpg, but it did address the underlying problem of the loss of transparency due to our legacy code. Does this jibe with everyone elses understanding?

> (In reply to comment #10) One of the things I noticed is that copy paste drops > transparency data from png files copied out of the content area. I believe this > is the reason why this bug was posted. Is that correct? The initial reason for this bug was apparently that an image originally in PNG format from an application (here Firefox) was put on the clipboard as CF_DIB object when copied on Windows, and then converted to a low-quality JPEG image when pasted into Thunderbird from there. The combination of the fixes for bug 384116 (editor) and bug 444800 (widgets) converts the CF_DIB now to either JPEG or PNG, based on the requested encoding flavor. As tested after today's checkin, this works fine and provides now the means to paste in lossless PNG also on Windows platforms. > The problem could probably be addressed by adding support for transparent bmp > formats in our rendering and receiving code. For example, the data for a copy > is rendered in nsImageToClipboard::CreateFromImage. The format we render to is > an outdated version of the windows bitmap format. The receiving code appears to > be in nsImageFromClipboard ::GetEncodedImageStream, which sufferes from the > same problem. Assuming that conversion from a PNG with transparency to CF_DIB on one side removes the transparency information, encoding it back into PNG format on the receiving end of course wouldn't have it either. If PNG directly or another format supporting transparency would be available on the Windows clipboard (I'm not sure if and how the transparency issue is handled by clipboard mechanisms of other platforms), this would certainly be helpful for those cases. Even though PNG-clipboard is mentioned in comment #3, I'd think that transparency wasn't the primary focus of this bug here from the initial description.

(In reply to comment #11) > The initial reason for this bug was apparently that an image originally in > PNG format from an application (here Firefox) was put on the clipboard as > CF_DIB object when copied on Windows, and then converted to a low-quality > JPEG image when pasted into Thunderbird from there. The combination of the > fixes for bug 384116 (editor) and bug 444800 (widgets) converts the CF_DIB > now to either JPEG or PNG, based on the requested encoding flavor. As tested > after today's checkin, this works fine and provides now the means to paste in > lossless PNG also on Windows platforms. So does that mean we can close this bug out as well or is there still work to do in this area? > Assuming that conversion from a PNG with transparency to CF_DIB on one side > removes the transparency information, encoding it back into PNG format on the > receiving end of course wouldn't have it either. If PNG directly or another > format supporting transparency would be available on the Windows clipboard (I'm > not sure if and how the transparency issue is handled by clipboard mechanisms > of other platforms), this would certainly be helpful for those cases. Yep, the newer bitmap format can handle that, including transparency. If we decide to close this one out or if it's related to some other work, I'll post another on this specifically. Thx.

(In reply to comment #12) > So does that mean we can close this bug out as well or is there still work to > do in this area? Given that the main issue of allowing to paste in PNG as alternative to JPEG should be satisfied by the editor and widget patches, we should be almost done. Open issues include the default JPEG pasting quality (bug 444898) and the question of that default being configurable in the editor (bug 456086). Those are indirectly dependent bugs through bug 444800. The issue of some possible user interface has been addressed in bug 460285, resulting in a won't-fix for that bug as an extension for this appeared to be a better solution than introducing it as a standard feature, thus it wouldn't make much sense to continue here either (point #3 of the list). > Yep, the newer bitmap format can handle that, including transparency. If we > decide to close this one out or if it's related to some other work, I'll post > another on this specifically. Thx. That's probably a follow-up bug in the widget component, but would certainly be related to the bugs here. We could make those bugs block the one here to keep track of them, if that would be helpful.

Jim filed bug 460969 on the transparency issue. Can anybody verify that pasting an image as PNG works on Mac OSX as well? In theory it should, the unit tests show image/png being pasted from the clipboard and the editor should pick it up, but I'm unable to explicitly test that (no Mac around). We would have all major platforms covered then and probably could close this bug as resolved by the other bugs.

Tested this in Mac OS X 10.5.5 with Thunderbird 3 (2008.11.14 3.0b1pre nightly). Opened known PNG in Preview, selected all, copied. Created new message in TB, pasted image and sent. Opened sent message, saved image to desktop. Opened PNG with Windows Macromedia Fireworks MX just fine. Renamed image (on Mac desktop) to have .jpg extension. Tried to open in Fireworks again and got error message - wrong file type, as expected. So, image that was pasted as PNG and saved, was, indeed, a PNG, not a jpg. PNG pasting as PNG (not as jpg) seems to work. --PAUL RIEGER

Thanks Paul. Thus, pasting in PNG format is verified possible now in all three major platforms, remaining issues on the JPEG quality can be resolved independently from the main task here. -> WFM (problem solved by fixes for other bugs).