OpenURL post data handling.

content/common/frame_messages.h

Index: content/common/frame_messages.h
diff --git a/content/common/frame_messages.h b/content/common/frame_messages.h
index 860be882ce92fec89511be3a3c5830a5a5c7bdd1..e580bd93f149b1e5eac6b6fa429a11f3b258a2e0 100644
--- a/content/common/frame_messages.h
+++ b/content/common/frame_messages.h
@@ -448,6 +448,9 @@ IPC_STRUCT_END()
 // the browser process should look for an existing history item for the frame.
 IPC_STRUCT_BEGIN(FrameHostMsg_OpenURL_Params)
   IPC_STRUCT_MEMBER(GURL, url)
+  IPC_STRUCT_MEMBER(bool, uses_post)
+  IPC_STRUCT_MEMBER(scoped_refptr<content::ResourceRequestBodyImpl>,
+                    resource_request_body)

[Łukasz Anforowicz, 2016/06/10 20:00:49]

Note that this is not the first time when we send ResourceRequestBody back into
the renderer process (i.e. we already do it in
content::ResourceRequest::request_body embedded in
ResourceHostMsg_RequestResource and a few other IPC messages).

This *is* the first time when ResourceRequestBody is passed above //content
layer, into the embedder.  OTOH, above //content ResourceRequestBody is opaque
[1], so I think we shouldn't be getting any extra exposure here.

[1] e.g. see the class comment in content/public/common/resource_request_body.h
in https://codereview.chromium.org/2038813003/patch/40001/50059

[nasko, 2016/06/10 20:22:28]

FrameHostMsg_OpenURL_Params cannot be seen outside of content/, so I don't think
adding the Impl to this IPC message is a problem. The handler of the IPC that
sends the results of it outside of content/ should be the one ensuring we only
expose the public interface.

   IPC_STRUCT_MEMBER(content::Referrer, referrer)
   IPC_STRUCT_MEMBER(WindowOpenDisposition, disposition)
   IPC_STRUCT_MEMBER(bool, should_replace_current_entry)