Force avatar and wallpaper decoding to use robust JPEG.

chrome/common/chrome_utility_messages.h

Index: chrome/common/chrome_utility_messages.h
diff --git a/chrome/common/chrome_utility_messages.h b/chrome/common/chrome_utility_messages.h
index 6750826455afb14c763751a0d69693c0d7a89a11..c0fca3eed0a0a6a1dc71f0f57b5862539f0de630 100644
--- a/chrome/common/chrome_utility_messages.h
+++ b/chrome/common/chrome_utility_messages.h
@@ -78,6 +78,11 @@ IPC_MESSAGE_CONTROL1(ChromeUtilityMsg_DecodeImage,
 IPC_MESSAGE_CONTROL1(ChromeUtilityMsg_DecodeImageBase64,
                      std::string)  // base64 encoded image contents
 
+// Tell the utility process to decode the given JPEG image data with standard
+// libjpeg codec.
+IPC_MESSAGE_CONTROL1(ChromeUtilityMsg_DecodeImageWithIJGlibjpeg,

[sky, 2012/08/29 15:21:54]

Why do we need a new message, can't we add an argument to the existing one?

[Jorge Lucangeli Obes, 2012/08/29 17:04:30]

The way I see this functionality, we're providing a new mechanism for more
robust (but slower) strictly-JPEG decoding.

The regular DecodeImage method supports a whole bunch of image formats. Adding a
second argument that would make most of the byte streams in the first argument
"invalid" sounds brittle.

As for the name, though, I would rather have a name that refers to the "what",
i.e. "RobustJPEGDecodeImage", rather than the "how"/implementation details, i.e.
mentioning IJG libjpeg. We might want to change/update how we do robust image
decoding, we should be able to change that in the utility process without
leaving an outdated message name here. The same would apply for an eventual
argument name.

+                     std::vector<unsigned char>)  // encoded image contents
+
 // Tell the utility process to render the given PDF into a metafile.
 IPC_MESSAGE_CONTROL4(ChromeUtilityMsg_RenderPDFPagesToMetafile,
                      base::PlatformFile,       // PDF file