Fix a crash when saving a <canvas> or <img> image which is large.

content/common/view_messages.h

Index: content/common/view_messages.h
diff --git a/content/common/view_messages.h b/content/common/view_messages.h
index 14efdaf160ec3a4def42d671b2624b47b37b9316..083570f738607e5677f141203ac5213488d8a51f 100644
--- a/content/common/view_messages.h
+++ b/content/common/view_messages.h
@@ -1252,12 +1252,18 @@ IPC_MESSAGE_ROUTED2(ViewHostMsg_AppCacheAccessed,
                     bool /* blocked by policy */)
 
 // Initiates a download based on user actions like 'ALT+click'.
-IPC_MESSAGE_CONTROL5(ViewHostMsg_DownloadUrl,
+IPC_MESSAGE_CONTROL4(ViewHostMsg_DownloadUrl,
                      int /* render_view_id */,
                      GURL /* url */,
                      content::Referrer /* referrer */,
-                     base::string16 /* suggested_name */,
-                     bool /* use prompt for save location */)
+                     base::string16 /* suggested_name */)
+
+// Save image for <canvas>.

[Ken Russell (switch to Gerrit), 2014/08/29 23:29:26]

Please document that |encoded_image_data| is the contents of a data: URL, and
that it's represented as a string only to work around size limitations for GURLs
in IPC messages.

+IPC_MESSAGE_CONTROL4(ViewHostMsg_SaveImageAs,
+                     int /* render_view_id */,
+                     std::string /* encoded_image_data */,

[Ken Russell (switch to Gerrit), 2014/08/29 23:29:26]

Some guard against DOS'ing the browser process is needed here. Using a GURL in
the IPC message imposes the limit content::GetMaxURLChars(). See
common_param_traits.cc.

I think doing the PNG and base64 encoding in the renderer process, as you're
currently doing, is a good idea. This usage just needs to pass security review.
Most of the time, using string instead of GURL violates the practices in
http://www.chromium.org/Home/chromium-security/education/security-tips-for-ipc .

[palmer, 2014/08/30 00:37:29]

Yeah, It's probably better to send the browser process a PNG as a
vector<uint8_t> or some kind of IPC-sendable image type, if we have one. And
then check a size limit (10 MiB or whatever seems reasonable) before sending,
and have the browser side enforce that limit.

[Ken Russell (switch to Gerrit), 2014/08/30 00:52:09]

Chris, in this case I think it's better to send the image over as the
base64-encoded PNG (the data: URL, essentially), because that way the renderer
process runs both the PNG encoder and base64 encoding. Do you agree?

Sending an SkBitmap is an option (it's done elsewhere) but again that moves the
PNG encoding to the browser process.

It would be possible to send the encoded PNG from the renderer, but that would
require more surgery in the renderer process to avoid an encode -> decode ->
encode step. Do you think this is worth it? Right now the code on both sides
wants to deal with the contents of a data: URL.

+                     content::Referrer /* referrer */,
+                     base::string16 /* suggested_name */)

[palmer, 2014/08/30 00:37:29]

Make sure the browser side (a) takes the basename of |suggested_name| (to avoid
being tricked into path traversal, e.g. ../../../../...); and (b) somehow
transforms it for sanity and uniqueness.

 
 // Used to go to the session history entry at the given offset (ie, -1 will
 // return the "back" item).