Better distinguish didFinishLoad and didStopLoading

third_party/WebKit/Source/core/loader/FrameLoader.cpp

Index: third_party/WebKit/Source/core/loader/FrameLoader.cpp
diff --git a/third_party/WebKit/Source/core/loader/FrameLoader.cpp b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
index 05fe06764a622b43a0f3a1bb6f29cff79696e1db..b4b640a37920bde26167e4fe8788d7ecaedaf680 100644
--- a/third_party/WebKit/Source/core/loader/FrameLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
@@ -529,37 +529,34 @@ static bool shouldComplete(Document* document)
     return allDescendantsAreComplete(document->frame());
 }
 
-static bool shouldSendCompleteNotifications(LocalFrame* frame)
+static bool shouldSendFinishNotification(LocalFrame* frame)
 {
     // Don't send stop notifications for inital empty documents, since they don't generate start notifications.
     if (!frame->loader().stateMachine()->committedFirstRealDocumentLoad())
         return false;
 
-    // FIXME: We might have already sent stop notifications and be re-completing.
-    if (!frame->isLoading())
+    // Don't send didFinishLoad more than once per DocumentLoader.
+    if (frame->loader().documentLoader()->sentDidFinishLoad())
         return false;
 
-    // The readystatechanged or load event may have disconnected this frame.

[dcheng, 2015/10/08 05:34:35]

Move this comment to 578 in the new file.

[Nate Chapin, 2015/10/08 21:03:59]

Done.

-    if (!frame->client())
+    // We might have declined to run the load event due to an imminent content-initiated navigation.

[dcheng, 2015/10/08 05:37:40]

This is probably a dumb question... content-initiated: is this referring to the
embedder, e.g. //content?

[Nate Chapin, 2015/10/08 21:03:59]

In this case, it means blink. I think it's the same terminology as in
RenderFrameImpl: browser-initiated is from the browser process,
content-initiated is from blink. That naming is unfortunate.

+    if (!frame->document()->loadEventFinished())
         return false;
 
     // An event might have restarted a child frame.
     if (!allDescendantsAreComplete(frame))
         return false;
+    return true;
+}
 
-    // An event might have restarted this frame by scheduling a new navigation.
-    if (frame->loader().provisionalDocumentLoader())
-        return false;
-
-    // A navigation is still scheduled in the embedder, so don't complete yet.
-    if (frame->loader().client()->hasPendingNavigation())
-        return false;
-
-    // We might have declined to run the load event due to an imminent content-initiated navigation.
-    if (!frame->document()->loadEventFinished())
+static bool shouldSendCompleteNotification(LocalFrame* frame)
+{
+    // FIXME: We might have already sent stop notifications and be re-completing.
+    if (!frame->isLoading())
         return false;
-
-    return true;
+    // Only send didStopLoading() if there are no navigations in progress at all,
+    // whether committed, provisional, or pending.
+    return frame->loader().documentLoader()->sentDidFinishLoad() && !frame->loader().provisionalDocumentLoader() && !frame->loader().client()->hasPendingNavigation();
 }
 
 void FrameLoader::checkCompleted()
@@ -578,7 +575,21 @@ void FrameLoader::checkCompleted()
     if (m_frame->view())
         m_frame->view()->handleLoadCompleted();
 
-    if (shouldSendCompleteNotifications(m_frame)) {
+    if (!m_frame->client())
+        return;
+
+    if (shouldSendFinishNotification(m_frame)) {
+        // Report mobile vs. desktop page statistics. This will only report on Android.
+        if (m_frame->isMainFrame())
+            m_frame->document()->viewportDescription().reportMobilePageStats(m_frame);
+        m_documentLoader->setSentDidFinishLoad();
+        client()->dispatchDidFinishLoad();
+        // Finishing the load can detach the frame when running layout tests.

[dcheng, 2015/10/08 05:34:35]

Can we fix this, maybe in a followup patch? This is the layout test runner doing
something crazy in didFinishLoad(), right?

[Nate Chapin, 2015/10/08 21:03:59]

I think the craziness is tearing down the test. I guess that could/should be
done async?

[dcheng, 2015/10/09 18:34:01]

Yeah, I think it'd make sense to do it async... when possible, I think we should
move in the direction of allowing less insanity in the WebFrameClient callbacks.

[Nate Chapin, 2015/10/09 18:39:44]

Agreed.

+        if (!m_frame->client())
+            return;
+    }
+
+    if (shouldSendCompleteNotification(m_frame)) {
         m_progressTracker->progressCompleted();
         // Retry restoring scroll offset since finishing loading disables content
         // size clamping.
@@ -586,11 +597,6 @@ void FrameLoader::checkCompleted()
 
         m_loadType = FrameLoadTypeStandard;
         m_frame->localDOMWindow()->finishedLoading();
-
-        // Report mobile vs. desktop page statistics. This will only report on Android.
-        if (m_frame->isMainFrame())
-            m_frame->document()->viewportDescription().reportMobilePageStats(m_frame);
-        client()->dispatchDidFinishLoad();
     }
 
     Frame* parent = m_frame->tree().parent();
@@ -1223,6 +1229,7 @@ void FrameLoader::receivedMainResourceError(DocumentLoader* loader, const Resour
         ASSERT(loader == m_documentLoader);
         if (m_frame->document()->parser())
             m_frame->document()->parser()->stopParsing();
+        m_documentLoader->setSentDidFinishLoad();
         if (!m_provisionalDocumentLoader && m_frame->isLoading()) {
             client()->dispatchDidFailLoad(error, historyCommitType);
             m_progressTracker->progressCompleted();