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

chrome/renderer/resources/extensions/web_view.js

Index: chrome/renderer/resources/extensions/web_view.js
diff --git a/chrome/renderer/resources/extensions/web_view.js b/chrome/renderer/resources/extensions/web_view.js
index c923edce7fadd8668c2767fa426bfe419f1cf289..b25208479c677c56d5e0cf1865f656b25ae6204c 100644
--- a/chrome/renderer/resources/extensions/web_view.js
+++ b/chrome/renderer/resources/extensions/web_view.js
@@ -11,8 +11,6 @@ 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 = [
@@ -100,16 +98,15 @@ function WebView(node) {
 
   // 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]);