Make the embedder responsible for creating the WebFrame

Source/web/WebFrameImpl.cpp

Index: Source/web/WebFrameImpl.cpp
diff --git a/Source/web/WebFrameImpl.cpp b/Source/web/WebFrameImpl.cpp
index eceb6899bc7fe030dc114d8793b801f48fac98ea..54184c6e0c1ab1e4a2dfa501ce364de8ad0e9eb0 100644
--- a/Source/web/WebFrameImpl.cpp
+++ b/Source/web/WebFrameImpl.cpp
@@ -50,7 +50,7 @@
 // ref initially and it is removed when the FrameLoader is getting destroyed.
 //
 // WebFrames are created in two places, first in WebViewImpl when the root
-// frame is created, and second in WebFrame::CreateChildFrame when sub-frames
+// frame is created, and second in WebFrame::createChildFrame when sub-frames
 // are created. WebKit will hook up this object to the FrameLoader/Frame
 // and the refcount will be correct.
 //
@@ -64,9 +64,12 @@
 // in FrameLoader::detachFromParent for each subframe.
 //
 // Frame going away causes the FrameLoader to get deleted. In FrameLoader's
-// destructor, it notifies its client with frameLoaderDestroyed. This calls
-// WebFrame::Closing and then derefs the WebFrame and will cause it to be
-// deleted (unless an external someone is also holding a reference).
+// destructor, it notifies its client with frameLoaderDestroyed. This derefs
+// the WebFrame and will cause it to be deleted (unless an external someone
+// is also holding a reference).
+//
+// Thie client is expected to be set whenever the WebFrameImpl is attached to
+// the DOM.
 
 #include "config.h"
 #include "WebFrameImpl.h"
@@ -266,12 +269,6 @@ static void frameContentAsPlainText(size_t maxChars, Frame* frame, StringBuilder
     }
 }
 
-static long long generateFrameIdentifier()
-{
-    static long long next = 0;
-    return ++next;
-}
-
 WebPluginContainerImpl* WebFrameImpl::pluginContainerFromFrame(Frame* frame)
 {
     if (!frame)
@@ -536,6 +533,12 @@ WebFrame* WebFrame::fromFrameOwnerElement(const WebElement& element)
     return WebFrameImpl::fromFrameOwnerElement(PassRefPtr<Element>(element).get());
 }
 
+void WebFrameImpl::close()

[darin (slow to review), 2013/09/13 04:02:47]

not that you should clean this up now, but WebFrameClient has a strange method
named willClose() that has no relation to this new method or
WebFrameClient::frameDetached(). it actually corresponds to the document for the
frame changing to another document. willClose means "the old document is being
closed."

+{
+    m_client = 0;
+    deref();  // Balances ref() acquired in WebFrame::create

[darin (slow to review), 2013/09/13 04:02:47]

nit: WebFrameImpl::create

+}

[darin (slow to review), 2013/09/13 04:02:47]

you might want to add a comment here explaining what this function is doing. you
might explain what it means for the embedder to signal that it has closed the
WebFrame, etc.

+
 WebString WebFrameImpl::uniqueName() const
 {
     return frame()->tree()->uniqueName();
@@ -2073,12 +2076,29 @@ WebString WebFrameImpl::layerTreeAsText(bool showDebugInfo) const
 
 // WebFrameImpl public ---------------------------------------------------------
 
-PassRefPtr<WebFrameImpl> WebFrameImpl::create(WebFrameClient* client)
+WebFrame* WebFrame::create(WebFrameClient* client)
+{
+    return WebFrameImpl::create(client, generateFrameIdentifier());
+}
+
+WebFrame* WebFrame::create(WebFrameClient* client, long long identifier)
+{
+    return WebFrameImpl::create(client, identifier);
+}
+
+long long WebFrame::generateFrameIdentifier()
 {
-    return adoptRef(new WebFrameImpl(client));
+    static long long next = 0;
+    // Assume that 64-bit will not wrap to -1.
+    return ++next;
 }
 
-WebFrameImpl::WebFrameImpl(WebFrameClient* client)
+WebFrameImpl* WebFrameImpl::create(WebFrameClient* client, long long identifier)
+{
+    return adoptRef(new WebFrameImpl(client, identifier)).leakRef();

[darin (slow to review), 2013/09/13 04:02:47]

nit: add a comment indicating that this leak gets cleaned up in
WebFrameImpl::close()

+}
+
+WebFrameImpl::WebFrameImpl(WebFrameClient* client, long long identifier)
     : FrameDestructionObserver(0)
     , m_frameLoaderClient(this)
     , m_client(client)
@@ -2095,7 +2115,7 @@ WebFrameImpl::WebFrameImpl(WebFrameClient* client)
     , m_nextInvalidateAfter(0)
     , m_findMatchMarkersVersion(0)
     , m_findMatchRectsAreValid(false)
-    , m_identifier(generateFrameIdentifier())
+    , m_identifier(identifier)

[darin (slow to review), 2013/09/13 04:02:47]

We should just move the concept of WebFrame identifier to Chromium. it doesn't
need to be part of Blink at all.  it was a mistake that it was ever put here.
this identifier can be a property of the content::RenderFrameImpl on the
Chromium side.

[awong, 2013/09/13 04:25:02]

I did this initially, but didn't know how to handle WebSharedWorkerImpl.cpp and
WebHelperPluginImpl.cpp. Both these create a WebFrameImpl outside the purview of
RenderFrameImpl.

WebHelplerPluginImpl in particular uses the mainframe's render_frame_impl as the
client.  I have no idea whether or not WebHelperPluginImpl executes resource
load requests.  If it does, then I think it needs to have a unique WebFrame
identifier which means I can't move the WebFrame identifier into render_view
just yet.

Do you know whether it'd be okay for WebHelperPluginImpl to not have a sensible
WebFrame identifier?

Further more, since the per-frame RenderFrameHostImpl creation is sitting behind
a flag, I can't make this transition yet.  Otherwise, I think I would break
resource loads on trunk. :'(

     , m_inSameDocumentHistoryLoad(false)
 {
     WebKit::Platform::current()->incrementStatsCounter(webFrameActiveCount);
@@ -2121,7 +2141,7 @@ void WebFrameImpl::initializeAsMainFrame(WebCore::Page* page)
     RefPtr<Frame> mainFrame = Frame::create(page, 0, &m_frameLoaderClient);
     setWebCoreFrame(mainFrame.get());
 
-    // Add reference on behalf of FrameLoader.  See comments in
+    // Add reference on behalf of FrameLoader. See comments in
     // WebFrameLoaderClient::frameLoaderDestroyed for more info.
     ref();
 
@@ -2132,7 +2152,8 @@ void WebFrameImpl::initializeAsMainFrame(WebCore::Page* page)
 
 PassRefPtr<Frame> WebFrameImpl::createChildFrame(const FrameLoadRequest& request, HTMLFrameOwnerElement* ownerElement)
 {
-    RefPtr<WebFrameImpl> webframe(adoptRef(new WebFrameImpl(m_client)));
+    ASSERT(m_client);
+    WebFrameImpl* webframe = static_cast<WebFrameImpl*>(m_client->createChildFrame(this, request.frameName()));
 
     // Add an extra ref on behalf of the Frame/FrameLoader, which references the
     // WebFrame via the FrameLoaderClient interface. See the comment at the top
@@ -2156,8 +2177,11 @@ PassRefPtr<Frame> WebFrameImpl::createChildFrame(const FrameLoadRequest& request
     // return without loading URL.
     // (b:791612)
     childFrame->init(); // create an empty document
-    if (!childFrame->tree()->parent())
+    if (!childFrame->tree()->parent()) {
+        if (m_client)
+            m_client->frameDetached(webframe);

[darin (slow to review), 2013/09/13 04:02:47]

there have been bugs where it appeared from the chromium side that frameDetached
was not called when it should have been. i wonder if you found the culprit to
those bugs.

         return 0;
+    }
 
     HistoryItem* parentItem = frame()->loader()->history()->currentItem();
     HistoryItem* childItem = 0;
@@ -2174,11 +2198,12 @@ PassRefPtr<Frame> WebFrameImpl::createChildFrame(const FrameLoadRequest& request
     // A synchronous navigation (about:blank) would have already processed
     // onload, so it is possible for the frame to have already been destroyed by
     // script in the page.
-    if (!childFrame->tree()->parent())
+    if (!childFrame->tree()->parent()) {
+        if (m_client)
+            m_client->frameDetached(webframe);
         return 0;
+    }
 
-    if (m_client)
-        m_client->didCreateFrame(this, webframe.get());
 
     return childFrame.release();
 }