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

content/common/view_messages.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // IPC messages for page rendering.
 // Multiply-included message file, hence no include guard.
 
 #include "base/memory/shared_memory.h"
 #include "base/process/process.h"
 #include "base/strings/string16.h"
@@ skipping 1234 matching lines @@
 IPC_MESSAGE_CONTROL1(ViewHostMsg_ForwardToWorker,
                      IPC::Message /* message */)
 
 // Tells the browser that a specific Appcache manifest in the current page
 // was accessed.
 IPC_MESSAGE_ROUTED2(ViewHostMsg_AppCacheAccessed,
                     GURL /* manifest url */,
                     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).
 IPC_MESSAGE_ROUTED1(ViewHostMsg_GoToEntryAtOffset,
                     int /* offset (from current) of history item to get */)
 
 // Sent from an inactive renderer for the browser to route to the active
 // renderer, instructing it to close.
 IPC_MESSAGE_ROUTED0(ViewHostMsg_RouteCloseEvent)
 
@@ skipping 399 matching lines @@
 // Since the browser keeps handles to the allocated transport DIBs, this
 // message is sent to tell the browser that it may release them when the
 // renderer is finished with them.
 IPC_MESSAGE_CONTROL1(ViewHostMsg_FreeTransportDIB,
                      TransportDIB::Id /* DIB id */)
 #endif
 
 // Adding a new message? Stick to the sort order above: first platform
 // independent ViewMsg, then ifdefs for platform specific ViewMsg, then platform
 // independent ViewHostMsg, then ifdefs for platform specific ViewHostMsg.