This is a spin-off from bug 444800, which in turn came from bug 384116. The patches for these bugs allow pasting in different formats (specifically PNG in addition to JPEG, also GIF if supported by the clipboard mechanism). It was observed that the content of the Windows clipboard is recoded by the Widgets code to JPEG, using the default quality (which is increased from 50 to 92 by bug 444898, along with improvements in sampling). A suggestion in bug 384116 comment #10 and the original description motivated making this a configuration option. The clipboard.paste_image_quality preference was introduced to specify the quality for JPEG encoding by libpr0n (of the main platforms, this appears to be currently only used on Windows). Other clipboard mechanisms perform JPEG conversion directly if that encoding is requested. Implementation of the pref was envisioned for Windows only, where bug 444800 focused on PNG/JPEG pasting, thus completing bug 384116 on the widget side, but without consideration of the JPEG quality. Thus, the charge for this bug is to investigate whether such a configuration option is needed, in addition to the ability to paste in high-quality JPEG and lossless PNG, or if the preference can be removed. If the decision is to keep the pref, it should further be determined for which platforms it can be actually implemented (thus far known for sure for Windows only).

This is merely for reference, not for review (yet). There is also an example in attachment 330456 [details] [diff] [review] on how the preference could be used with the JPEG encoder for the Windows clipboard. The code for bug 384116 got checked into mozilla/comm-central only, not into CVS for any branches.

If the default quality will remain 92 for the forseeable future, then the only reason to retain a settable quality is for file-size savings (trading off the relatively poor image quality obtained by setting it to 50 or 60 for a fairly significant reduction in filesize). I had posted some very limited test results in bug #444898 which show filesize of quality 90 being 2.5 to 4 times the size of quality 50.

While Glenn is making a good point, I don't see much excitement here that somebody wants to implement this configuration option. Furthermore, per https://wiki.mozilla.org/Firefox3.1/Schedule the feature freeze for 1.9.1 technically has been reached already with the first beta released. How shall we proceed here? Since it is unlikely to make it into 1.9.1, but on the other hand it wouldn't be good to have a non-functional preference around, should I request review for attachment 339533 [details] [diff] [review] to remove it for now? It would be easy to add back with any patch implementing this option.

Comment on attachment 339533 [details] [diff] [review] Patch to remove unimplemented pref [Checkin: Comment 8] moa/r=brade

Thanks for the reviews. It doesn't appear that composer.js is actually part of the Firefox 3.1b2 build, thus I assume that this can be pushed to trunk without requesting approval1.9.1 explicitly.

rsx11m.pub, I would prefer if you could register your first and last name or at least an alias. Thanks.

Done, my alias is the same as I'm using on MozillaZine and the Mozilla Wiki. Will this bug be closed after the check-in? If yes, I should probably adjust summary and flags of this bug to what was actually done here.

Comment on attachment 339533 [details] [diff] [review] Patch to remove unimplemented pref [Checkin: Comment 8] http://hg.mozilla.org/comm-central/rev/8158cce0a416 NB: For future patches, use Unix EOLs. Thanks.

(In reply to comment #7) > Will this bug be closed after the check-in? Considering the current outcome, I think it's simpler to resolve this bug. Fill free to open a new (Core) one, if need be.

Thanks, and sorry for the newlines (depends on where the patch was made). That's Core/Editor though, affecting both SeaMonkey and Thunderbird. Considering this closed then. If anybody wants to resurrect and implement the preference, please open a new Core/Widget bug for the respective platform.