[SCM] WebKit Debian packaging branch, debian/experimental, updated. upstream/1.3.3-9427-gc2be6fc

[tonyg at chromium.org]

The following commit has been merged in the debian/experimental branch:
commit 8ba8bd5e32e04d4d6e10f2e9d09c4c6f70d2091c
Author: tonyg at chromium.org <tonyg at chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Thu Jul 22 07:40:52 2010 +0000

    2010-07-22  Tony Gentilcore  <tonyg at chromium.org>
    
            Reviewed by Darin Fisher.
    
            webkitPerformance.timing.responseEnd should not include document parse time
            https://bugs.webkit.org/show_bug.cgi?id=42797
    
            No new tests because timing based test would be flaky.
    
            * loader/FrameLoader.cpp:
            (WebCore::FrameLoader::finishedLoading): finishedLoading() is called by the platform at the right time, but didReceiveData() synchronously invokes parsing without returning to the event loop prior to this. So by the time the didFinishLoading() method is executed, parsing is finished. The solution is to move this time to didReceiveData() prior to parsing.
            * loader/MainResourceLoader.cpp:
            (WebCore::MainResourceLoader::didReceiveData): Update the time each time didReceiveData() is called.
            (WebCore::MainResourceLoader::didFinishLoading): When finished, and after parsing, set responseEnd appropriately.
            * loader/MainResourceLoader.h:
            * page/Timing.cpp:
            (WebCore::Timing::resourceLoadTimeRelativeToAbsolute): Now that responseEnd is set correctly, it can be much shorter for very fast loads (like local files). This exposed the fact that this skew check was not tight enough. We need to make sure that the whole range of values from the ResourceLoadTiming API fit within fetchStart-responseEnd, not just that requestTime fits in this range.
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@63878 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog
index ad5ed03..97db8ed 100644
--- a/WebCore/ChangeLog
+++ b/WebCore/ChangeLog
@@ -1,3 +1,21 @@
+2010-07-22  Tony Gentilcore  <tonyg at chromium.org>
+
+        Reviewed by Darin Fisher.
+
+        webkitPerformance.timing.responseEnd should not include document parse time
+        https://bugs.webkit.org/show_bug.cgi?id=42797
+
+        No new tests because timing based test would be flaky.
+
+        * loader/FrameLoader.cpp:
+        (WebCore::FrameLoader::finishedLoading): finishedLoading() is called by the platform at the right time, but didReceiveData() synchronously invokes parsing without returning to the event loop prior to this. So by the time the didFinishLoading() method is executed, parsing is finished. The solution is to move this time to didReceiveData() prior to parsing.
+        * loader/MainResourceLoader.cpp:
+        (WebCore::MainResourceLoader::didReceiveData): Update the time each time didReceiveData() is called.
+        (WebCore::MainResourceLoader::didFinishLoading): When finished, and after parsing, set responseEnd appropriately.
+        * loader/MainResourceLoader.h:
+        * page/Timing.cpp:
+        (WebCore::Timing::resourceLoadTimeRelativeToAbsolute): Now that responseEnd is set correctly, it can be much shorter for very fast loads (like local files). This exposed the fact that this skew check was not tight enough. We need to make sure that the whole range of values from the ResourceLoadTiming API fit within fetchStart-responseEnd, not just that requestTime fits in this range.
+
 2010-07-21  Kent Tamura  <tkent at chromium.org>
 
         Reviewed by Darin Adler.
diff --git a/WebCore/loader/FrameLoader.cpp b/WebCore/loader/FrameLoader.cpp
index efda6af..7127148 100644
--- a/WebCore/loader/FrameLoader.cpp
+++ b/WebCore/loader/FrameLoader.cpp
@@ -2221,8 +2221,6 @@ void FrameLoader::finishedLoading()
     RefPtr<Frame> protect(m_frame);
 
     RefPtr<DocumentLoader> dl = activeDocumentLoader();
-    ASSERT(!dl->timing()->responseEnd);
-    dl->timing()->responseEnd = currentTime();
     dl->finishedLoading();
     if (!dl->mainDocumentError().isNull() || !dl->frameLoader())
         return;
diff --git a/WebCore/loader/MainResourceLoader.cpp b/WebCore/loader/MainResourceLoader.cpp
index 504a5ea..f16d640 100644
--- a/WebCore/loader/MainResourceLoader.cpp
+++ b/WebCore/loader/MainResourceLoader.cpp
@@ -413,6 +413,8 @@ void MainResourceLoader::didReceiveData(const char* data, int length, long long
     // reference to this object; one example of this is 3266216.
     RefPtr<MainResourceLoader> protect(this);
 
+    m_timeOfLastDataReceived = currentTime();
+
     ResourceLoader::didReceiveData(data, length, lengthReceived, allAtOnce);
 }
 
@@ -432,6 +434,8 @@ void MainResourceLoader::didFinishLoading()
     RefPtr<DocumentLoader> dl = documentLoader();
 #endif
 
+    ASSERT(!documentLoader()->timing()->responseEnd);
+    documentLoader()->timing()->responseEnd = m_timeOfLastDataReceived;
     frameLoader()->finishedLoading();
     ResourceLoader::didFinishLoading();
     
diff --git a/WebCore/loader/MainResourceLoader.h b/WebCore/loader/MainResourceLoader.h
index 5ed0cc8..e2d075c 100644
--- a/WebCore/loader/MainResourceLoader.h
+++ b/WebCore/loader/MainResourceLoader.h
@@ -107,6 +107,7 @@ namespace WebCore {
 
         bool m_loadingMultipartContent;
         bool m_waitingForContentPolicy;
+        double m_timeOfLastDataReceived;
     };
 
 }
diff --git a/WebCore/page/Timing.cpp b/WebCore/page/Timing.cpp
index 527390a..1eeceb6 100644
--- a/WebCore/page/Timing.cpp
+++ b/WebCore/page/Timing.cpp
@@ -290,7 +290,7 @@ unsigned long long Timing::resourceLoadTimeRelativeToAbsolute(int relativeSecond
     //
     // Since ResourceLoadTimings came from the network platform layer, we must
     // check them for skew because they may be from another thread/process.
-    double baseTime = getPossiblySkewedTimeInKnownRange(resourceTiming->requestTime, documentTiming->fetchStart, documentTiming->responseEnd);
+    double baseTime = getPossiblySkewedTimeInKnownRange(resourceTiming->requestTime, documentTiming->fetchStart, documentTiming->responseEnd - (resourceTiming->receiveHeadersEnd / 1000.0));
     return toIntegerMilliseconds(baseTime) + relativeSeconds;
 }
 

-- 
WebKit Debian packaging