Switch RemoteWindowProxy to use v8::Context::NewRemoteContext.

third_party/WebKit/Source/bindings/core/v8/WindowProxy.h

Index: third_party/WebKit/Source/bindings/core/v8/WindowProxy.h
diff --git a/third_party/WebKit/Source/bindings/core/v8/WindowProxy.h b/third_party/WebKit/Source/bindings/core/v8/WindowProxy.h
index f0771472661215df06daac7140ece13a2cc96c92..969890ae34040f0dee0e15b6b4aafee7222f1528 100644
--- a/third_party/WebKit/Source/bindings/core/v8/WindowProxy.h
+++ b/third_party/WebKit/Source/bindings/core/v8/WindowProxy.h
@@ -31,6 +31,7 @@
 #ifndef WindowProxy_h
 #define WindowProxy_h
 
+#include <v8.h>
 #include "bindings/core/v8/DOMWrapperWorld.h"
 #include "bindings/core/v8/ScopedPersistent.h"
 #include "core/CoreExport.h"
@@ -101,9 +102,9 @@ class Frame;
 // frame were cross-origin. This is due to complexities in the process
 // allocation model for renderer processes. See https://crbug.com/601629.
 //
-// ====== LocalWindowProxy/RemoteWindowProxy ======
-// Currently, the prototype chain for LocalWindowProxy and RemoteWindowProxy
-// look the same:
+// ====== LocalWindowProxy ======
+// Since a LocalWindowProxy can represent a same-origin or cross-origin frame,
+// the entire prototype chain must be available:
 //
 //   outer global proxy
 //     -- has prototype --> inner global object
@@ -115,8 +116,25 @@ class Frame;
 //
 // [1] WindowProperties is the named properties object of the Window interface.
 //
-// There is work in progress to refactor RemoteWindowProxy to use remote v8
-// contexts, to reduce the overhead of remote frames.
+// ====== RemoteWindowProxy ======
+// Since a RemoteWindowProxy only represents a cross-origin frame, it has a much
+// simpler prototype chain.
+//
+//   outer global proxy
+//     -- has prototype --> inner global object
+//     -- has prototype --> null
+//
+// Property access to get/set attributes and methods on the outer global proxy
+// are redirected through the cross-origin interceptors, since any access will
+// fail the security check, by definition.
+//
+// However, note that method invocations still use the inner global object as
+// the receiver object. Blink bindings use v8::Signature to perform a strict
+// receiver check, which requires that the FunctionTemplate used to instantiate
+// the receiver object matches exactly. However, when creating a new context,
+// only inner global object is instantiated using Blink's global template, so by
+// definition, it is the only receiver object in the prototype chain that will
+// match.
 //
 // ====== References ======
 // https://wiki.mozilla.org/Gecko:SplitWindow