Introduce WebFrameWidget to Blink

Source/web/WebLocalFrameImpl.h

Index: Source/web/WebLocalFrameImpl.h
diff --git a/Source/web/WebLocalFrameImpl.h b/Source/web/WebLocalFrameImpl.h
index 07abc774de53cb9174cc471422c5dee15be888e4..113ca6afec9c391f5eb644d4ec5ae7bb746716b3 100644
--- a/Source/web/WebLocalFrameImpl.h
+++ b/Source/web/WebLocalFrameImpl.h
@@ -55,6 +55,7 @@ class TextFinder;
 class WebAutofillClient;
 class WebDataSourceImpl;
 class WebFrameClient;
+class WebFrameWidgetImpl;
 class WebPerformance;
 class WebPlugin;
 class WebPluginContainerImpl;
@@ -317,6 +318,9 @@ public:
     // Returns a hit-tested VisiblePosition for the given point
     VisiblePosition visiblePositionForWindowPoint(const WebPoint&);
 
+    void setFrameWidget(WebFrameWidgetImpl*);
+    WebFrameWidgetImpl* frameWidget();
+
 #if ENABLE(OILPAN)
     void trace(Visitor*);
 #endif
@@ -340,6 +344,9 @@ private:
     // FIXME: These will need to change to WebFrame when we introduce WebFrameProxy.
     RefPtrWillBeMember<LocalFrame> m_frame;
 
+    // This is set if the frame is the root of a local frame tree, and requires a widget for rendering.
+    WebFrameWidgetImpl* m_frameWidget;

[dcheng, 2014/12/16 20:13:06]

Should WebLocalFrame own the WebFrameWidget? It seems like their lifetimes
should be tied together.

[kenrb, 2014/12/16 22:04:12]

The model I had in mind was this:
RenderFrame owns RenderWidget
RenderFrame owns WebLocalFrame
RenderWidget owns WebFrameWidget

[dcheng, 2014/12/16 23:20:20]

I think this is problematic. It's fine for RenderFrame to own a RenderWidget. I
don't think we should have parallel ownership hierarchies for WebLocalFrame and
WebFrameWidget though. The WebLocalFrame should own its WebFrameWidget if it has
one.

I think this is important because we're exposing WebLocalFrame/WebFrameWidget
from the Blink API layer. Having setFrameWidget() and setLocalRoot() exposes
this internal state management to content, which is something I'd prefer not to
do.

At least from what I can tell, this should lead to a pretty straightforward API:
- WebRemoteFrame::createLocalFrame() always needs to call the
WebLocalFrame::createWithWidget() overload.
- content::RenderViewImpl (or whatever content class ends up responsible for
creating the main frame) always calls WebLocalFrame::createWithWidget().
- content::RenderFrameImpl::createChildFrame() always uses
WebLocalFrame::create().

[kenrb, 2014/12/17 14:52:31]

I see what you are saying, but my concern is that it creates inconsistency in
the Blink API leading to more complex content code. Currently there are 2 kinds
WebWidget, and in both cases it is owned by RenderWidget (WebView/WebWidget, and
WebPagePopupImpl -- the first of those will go away eventually but the second
will not). RenderWidget has a pointer to a WebWidget and it would create
inter-layer complexity to have to differentiate between owned and non-owned
WebWidgets.

The Chromium patch is here:
https://codereview.chromium.org/616133002/

+
     WebFrameClient* m_client;
     WebAutofillClient* m_autofillClient;
     WebPermissionClient* m_permissionClient;