<webview>: Make contentWindow available prior to attachment (on display:none).

content/public/browser/guest_proxy_host.h

+// Copyright 2014 The Chromium Authors. All rights reserved.

[lfg, 2015/03/04 19:10:20]

2015

[Fady Samuel, 2015/03/05 20:56:23]

Done.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// This module provides class that serves as a public interface for a

[Charlie Reis, 2015/03/04 20:08:36]

The class level comment should go at line 20, below the ifndef and includes.

[Fady Samuel, 2015/03/05 20:56:23]

Done.

+// derived object that can size a guest.

[lfg, 2015/03/04 19:10:20]

Old comment?

[Fady Samuel, 2015/03/05 20:56:23]

Deleted.

+
+// This class currently only serves as a base class for BrowserPluginGuest, and
+// its API can only be accessed by a BrowserPluginGuestDelegate. This module
+// will go away once the migration to RenderFrame architecture has completed
+// (http://crbug.com/330264).
+
+#ifndef CONTENT_PUBLIC_BROWSER_GUEST_PROXY_HOST_H_
+#define CONTENT_PUBLIC_BROWSER_GUEST_PROXY_HOST_H_
+
+#include "ui/gfx/geometry/size.h"
+
+namespace content {
+
+class GuestProxyHost {

[Charlie Reis, 2015/03/04 20:08:36]

I'm hesitant to expose the concept of proxy hosts outside content/.  Is the TODO
above accurate, that this will go away when <webview> moves from BrowserPlugin
to RenderFrames?

[Fady Samuel, 2015/03/05 20:56:23]

This is not really the same as RenderFrameProxyHost (although related). There is
a 'GuestView' (really should be called GuestProxy' javascript object exposed to
<*view> developers (developers writing new view elements). This represents the
browser-process C++ backing to it, and hence "ProxyHost".

We didn't have a way to call back into the content module previously. This gives
us a way to call back into the content module. This can't be done generally, but
just for guests.

[Charlie Reis, 2015/03/06 00:05:35]

I notice that you've removed the TODO.  Are we going to have to keep this after
moving to the OOPIF infrastructure?
Ah.  That doesn't come across in the class declaration.  Could you explain the
reasoning in the comment?
That's kind of my concern.  Why does code outside content have to tell content
to create swapped out RenderViews?  That seems like something content should
manage on its own.

+ public:
+  // Returns the routing ID for the RenderView proxy for the guest in the
+  // owner's guest process if one has been created. If one has not been created
+  // then MSG_ROUTING_NONE is returned.
+  virtual int GetGuestProxyRoutingID() const = 0;
+
+  // Creates a RenderView proxy for the guest in the owner's process.

[Charlie Reis, 2015/03/04 20:08:36]

Please make it clear that this either creates or returns the existing one.

[Fady Samuel, 2015/03/05 20:56:23]

Done.

+  // This allows for a postMessage connection between processes.
+  virtual int GetOrCreateGuestProxyInOwnerProcess() = 0;
+
+  // Sets the size of the guest WebContents.
+  virtual void SizeContents(const gfx::Size& new_size) = 0;
+
+  // Called when the GuestProxyHost is about to be destroyed.
+  virtual void WillDestroy() = 0;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_GUEST_PROXY_HOST_H_