<webview>: Workaround to enable webview.contentWindow.postMessage.

chrome/renderer/resources/extensions/web_view.js

 // Copyright (c) 2012 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.
 
 // Shim that simulates a <webview> tag via Mutation Observers.
 //
 // The actual tag is implemented via the browser plugin. The internals of this
 // are hidden via Shadow DOM.
 
 var watchForTag = require("tagWatcher").watchForTag;
 
 var WEB_VIEW_ATTRIBUTES = ['src', 'partition'];
 
-var WEB_VIEW_READONLY_ATTRIBUTES = ['contentWindow'];
-
 // All exposed api methods for <webview>, these are forwarded to the browser
 // plugin.
 var WEB_VIEW_API_METHODS = [
   'back',
   'canGoBack',
   'canGoForward',
   'forward',
   'getProcessId',
   'go',
   'reload',
@@ skipping 67 matching lines @@
       },
       set: function(value) {
         objectNode[attributeName] = value;
       },
       enumerable: true
     });
   }, this);
 
   // We cannot use {writable: true} property descriptor because we want dynamic
   // getter value.
-  WEB_VIEW_READONLY_ATTRIBUTES.forEach(function(attributeName) {
-    Object.defineProperty(this.node_, attributeName, {
-      get: function() {
-        // Read these attributes from the plugin <object>.
-        return objectNode[attributeName];
-      },
-      // No setter.
-      enumerable: true
-    })
-  }, this);
+  Object.defineProperty(this.node_, 'contentWindow', {

[lazyboy, 2012/12/11 16:20:15]

Hopefully this doesn't break other properties with contentWindow.
What else (other than postMessage) can we do with <webview>.contentWindow? Can
we check if they still work properly?

[Charlie Reis, 2012/12/11 21:30:12]

I'm a bit nervous about this, but maybe it's the right thing to do.

Can you explain more about the original bug?  What is contentWindow actually
pointing to, and why is contentWindow.frames the right answer?

At least for the time being, I don't think we support any other uses of
contentWindow than postMessage (e.g., no openers, no traversal of frame trees,
no close(), focus(), etc), so it might not be a big problem.  I want to
understand why it fixes the bug, though, to be sure.

[Fady Samuel, 2012/12/11 21:46:01]

My understanding of the WebKit bug is we're creating an object wrapper around
the the v8 window object of the swapped out RenderView.

When we call browserPlugin.contentWindow.postMessage it seems like it's being
called in the context of the wrapper instead of the context of the window
object. Thus, postMessage fails. browserPlugin.contentWindow.frames escapes this
wrapper and so we get the window object and the correct context for postMessage.

For example console.log(browserPlugin.contentWindow) returns 'Object' as the
type, whereas console.log(browserPlugin.contentWindow.frames) returns 'Window'.

Actually, it looks like browserPlugin.contentWindow.self also escapes the
wrapper if that's preferable. 

+    get: function() {
+      // TODO(fsamuel): This is a workaround to enable
+      // contentWindow.postMessage until http://crbug.com/152006 is fixed.
+      return objectNode.contentWindow.frames;

[sadrul, 2012/12/11 01:48:56]

Hm. I don't know enough about contentWindow to know what this really means.
Perhaps someone who knows JS could review instead?

+    },
+    // No setter.
+    enumerable: true
+  });
 
   for (var eventName in WEB_VIEW_EVENTS) {
     this.setupEvent_(eventName, WEB_VIEW_EVENTS[eventName]);
   }
 }
 
 /**
  * @private
  */
 WebView.prototype.handleMutation_ = function(mutation) {
@@ skipping 16 matching lines @@
   var node = this.node_;
   this.objectNode_.addEventListener('-internal-' + eventname, function(e) {
     var evt = new Event(eventname);
     var detail = e.detail ? JSON.parse(e.detail) : {};
     attribs.forEach(function(attribName) {
       evt[attribName] = detail[attribName];
     });
     node.dispatchEvent(evt);
   });
 }