Update comments in WindowProxy to match current implementation.

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

 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 85 matching lines @@
 //   different process, i.e. a RemoteFrame.
 //
 // While having a RemoteFrame implies the frame must be cross-origin, the
 // opposite is not true: a LocalFrame can be same-origin or cross-origin. One
 // additional complexity (which slightly violates the HTML standard): it is
 // possible to have SecurityOrigin::canAccess() return true for a RemoteFrame's
 // security origin; however, it is important to still deny access as if the
 // 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
 //     -- has prototype --> Window.prototype
 //     -- has prototype --> WindowProperties [1]
 //     -- has prototype --> EventTarget.prototype
 //     -- has prototype --> Object.prototype
 //     -- has prototype --> null
 //
 // [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
 // https://whatwg.org/C/browsers.html#the-windowproxy-exotic-object
 class WindowProxy : public GarbageCollectedFinalized<WindowProxy> {
  public:
   virtual ~WindowProxy();
 
   DECLARE_TRACE();
 
@@ skipping 55 matching lines @@
  protected:
   // TODO(dcheng): Consider making these private and using getters.
   const RefPtr<DOMWrapperWorld> m_world;
   ScopedPersistent<v8::Object> m_globalProxy;
   Lifecycle m_lifecycle;
 };
 
 }  // namespace blink
 
 #endif  // WindowProxy_h