Start replicating sandbox flags for OOPIF

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 31fa6039d956dcf194fc077a6440a4dd1cce9896..be68d2d72629e829c2498c4ad2167e7ec82fb4e9 100644
--- a/content/common/frame_messages.h
+++ b/content/common/frame_messages.h
@@ -44,6 +44,7 @@ IPC_ENUM_TRAITS_MAX_VALUE(FrameMsg_UILoadMetricsReportType::Value,
 IPC_ENUM_TRAITS_MAX_VALUE(blink::WebContextMenuData::MediaType,
                           blink::WebContextMenuData::MediaTypeLast)
 IPC_ENUM_TRAITS_MAX_VALUE(ui::MenuSourceType, ui::MENU_SOURCE_TYPE_LAST)
+IPC_ENUM_TRAITS(content::SandboxFlags)  // Bitmask.

[alexmos, 2015/01/08 01:51:41]

This results in a presubmit warning about IPC_ENUM_TRAITS being deprecated, but
I'm not sure what the right thing is for bitmasks.  Other places in the code
seem to use this.

[Charlie Reis, 2015/01/08 22:17:26]

The deprecation warning points you to use IPC_ENUM_TRAITS_MIN_MAX_VALUE instead:
http://www.chromium.org/Home/chromium-security/education/security-tips-for-ipc

[dcheng, 2015/01/09 07:56:57]

It's fine to use IPC_ENUM_TRAITS in this situation
(https://groups.google.com/a/chromium.org/d/msg/chromium-reviews/ew61eyctSfw/s...
for a reference that's not just me =). Obviously, code that uses this will want
to be careful when using this value. I'm almost tempted to say we should have
another IPC_ENUM_TRAITS macro for this that at least checks that you don't pass
any out-of-range bits... but IIRC, SandboxFlags defines the -1 flag to be ALL,
so it doesn't really matter.

 
 IPC_STRUCT_TRAITS_BEGIN(content::ColorSuggestion)
   IPC_STRUCT_TRAITS_MEMBER(color)
@@ -226,6 +227,7 @@ IPC_STRUCT_TRAITS_END()
 
 IPC_STRUCT_TRAITS_BEGIN(content::FrameReplicationState)
   IPC_STRUCT_TRAITS_MEMBER(origin)
+  IPC_STRUCT_TRAITS_MEMBER(sandbox_flags)
 IPC_STRUCT_TRAITS_END()
 
 IPC_STRUCT_BEGIN(FrameMsg_Navigate_Params)
@@ -385,10 +387,11 @@ IPC_MESSAGE_ROUTED0(FrameMsg_DisownOpener)
 // |parent_routing_id| or as top level if that is MSG_ROUTING_NONE.
 // If a valid |proxy_routing_id| is provided, the new frame will be configured
 // to replace the proxy on commit.
-IPC_MESSAGE_CONTROL3(FrameMsg_NewFrame,
+IPC_MESSAGE_CONTROL4(FrameMsg_NewFrame,
                      int /* routing_id */,
                      int /* parent_routing_id */,
-                     int /* proxy_routing_id */)
+                     int /* proxy_routing_id */,
+                     content::FrameReplicationState /* replication_state */)

[alexmos, 2015/01/08 01:51:41]

Not actually sure whether to pass just the sandbox flags or the whole
FrameReplicationState here, which I originally intended for remote frames, not
local frames.  An advantage of using FrameReplicationState is that we can also
use it to pass things like the frame's name later.

[Charlie Reis, 2015/01/08 22:17:26]

I suppose it depends on what we expect to end up in FrameReplicationState.  It
does seem intended for remote frames, but if most of its members are needed when
doing a remote -> local swap, then maybe it's the right thing.  I admit that it
feels odd to pass origin and sizing info to a new local frame, when those are
ignored and handled in other ways.

If the answer is unclear, I'd suggest passing just the SandboxFlags for now.

[alexmos, 2015/01/09 20:43:25]

After tinkering with window.name replication, it may be a bit easier to keep
this as a FrameReplicationState, since otherwise I'd need to update this again
to also take the frame name.

Maybe down the road we should have separate structs, LocalFrameReplicationState
and RemoteFrameReplicationState, if we end up with several things like origin
that are not going to be used?

[Charlie Reis, 2015/01/12 20:25:11]

Yes, let's keep that in mind, in case we end up with multiple mutually exclusive
fields.  Better not to use the same struct for that.

 
 // Instructs the renderer to create a new RenderFrameProxy object with
 // |routing_id|. The new proxy should be created as a child of the object
@@ -560,9 +563,10 @@ IPC_MESSAGE_ROUTED4(FrameHostMsg_AddMessageToConsole,
 //
 // Each of these messages will have a corresponding FrameHostMsg_Detach message
 // sent when the frame is detached from the DOM.
-IPC_SYNC_MESSAGE_CONTROL2_1(FrameHostMsg_CreateChildFrame,
+IPC_SYNC_MESSAGE_CONTROL3_1(FrameHostMsg_CreateChildFrame,
                             int32 /* parent_routing_id */,
                             std::string /* frame_name */,
+                            content::SandboxFlags /* sandbox flags */,
                             int32 /* new_routing_id */)
 
 // Sent by the renderer to the parent RenderFrameHost when a child frame is