Pass origin information for remote frame creation.

content/common/frame_replication_state.h

Index: content/common/frame_replication_state.h
diff --git a/content/common/frame_replication_state.h b/content/common/frame_replication_state.h
new file mode 100644
index 0000000000000000000000000000000000000000..2bdf2d223b46defad673e90fba3c74860aff4e08
--- /dev/null
+++ b/content/common/frame_replication_state.h
@@ -0,0 +1,32 @@
+// Copyright 2014 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.
+
+#ifndef CONTENT_FRAME_REPLICATION_STATE_H_
+#define CONTENT_FRAME_REPLICATION_STATE_H_
+
+#include "content/common/content_export.h"
+#include "url/origin.h"
+
+namespace content {
+
+// This structure holds information that needs to be replicated from a local

[Charlie Reis, 2014/11/13 18:00:58]

Let's use the content names for LocalFrame and RemoteFrame here: RenderFrame /
RenderFrameProxies.

[alexmos, 2014/11/18 18:25:32]

Done.

+// frame to any of its associated remote frames.
+struct CONTENT_EXPORT FrameReplicationState {
+  FrameReplicationState();
+  ~FrameReplicationState();
+
+  // Current security origin of the frame (can be empty for unique origins).
+  url::Origin origin;

[alexmos, 2014/11/12 00:05:47]

Is using url::Origin the right thing here?  Although it emphasizes that this is
an origin rather than any URL, it's also inflexible (can't extract parts of
origin, can't properly support unique origins which is why I have the flag for
that below, doesn't have canAccess which we will need in the future).  A GURL
could be slightly better, though it still won't handle unique origins. 
blink::WebSecurityOrigin may be even better, but I don't know if it's allowed to
use that here.  Thoughts?

[Charlie Reis, 2014/11/13 18:00:58]

Hmm,  I agree that url::Origin seems a bit limited for our needs, but we
generally can't use arbitrary Blink classes outside the renderer process.  I've
seen WebSecurityOrigin discussed in the past (e.g., on
https://codereview.chromium.org/452013002/), so I'm pretty sure we won't be able
to use that.

Let's discuss options a bit more in person.

[alexmos, 2014/11/18 18:25:32]

After our discussion, and reading the discussion on the CL for adding
url::Origin (https://codereview.chromium.org/170843007/), I'm keeping it as an
url::Origin for now.  Short-term, I think the browser process can just see this
as an opaque serialized origin, and let Blink handle serialization and
deserialization.  This works fine for unique origins as well (which use the
string "null" per RFC 6454), so we don't need the is_unique_origin flag.  We
will need to start beefing up url::Origin (or switch to a richer class) once the
browser process is ready to start interpreting/verifying this origin, which as I
understand is not very soon.  Still worth checking on plans for url::Origin with
tsepez@ and abarth@, but I don't think it's blocking this.

+
+  // Whether the origin is unique.
+  bool is_unique_origin;
+
+  // TODO(alexmos): Add other properties of SecurityOrigins, such as
+  // SandboxFlags.  Eventually, this structure can also hold other state that
+  // needs to be replicated, such as frame sizing info.
+};
+
+}  // namespace content
+
+#endif // CONTENT_FRAME_REPLICATION_STATE_H_