[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 78612faa359adcfe767e8682429a4bc87d031b23
Author: tonyg at chromium.org <tonyg at chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Fri Jul 16 19:20:54 2010 +0000

    2010-07-16  Tony Gentilcore  <tonyg at chromium.org>
    
            Reviewed by Pavel Feldman.
    
            Fix unit error in calculating timings from ResourceLoadTiming API
            https://bugs.webkit.org/show_bug.cgi?id=42473
    
            The start and end offsets are already in milliseconds so they should not be multiplied by 1000.0 like requestTime.
    
            No new tests because, for a yet unknown reason, the ResourceLoadTiming API is not populated in the chromium test shell like it is in full chromium. This means the test that would have caught this bug (fast/dom/webtiming.html) currently has its expectation set to FAIL.
    
            * page/Timing.cpp:
            (WebCore::Timing::domainLookupStart):
            (WebCore::Timing::domainLookupEnd):
            (WebCore::Timing::connectStart):
            (WebCore::Timing::connectEnd):
            (WebCore::Timing::requestStart):
            (WebCore::Timing::requestEnd):
            (WebCore::Timing::responseStart):
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@63569 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog
index 96726d6..b14411d 100644
--- a/WebCore/ChangeLog
+++ b/WebCore/ChangeLog
@@ -1,3 +1,23 @@
+2010-07-16  Tony Gentilcore  <tonyg at chromium.org>
+
+        Reviewed by Pavel Feldman.
+
+        Fix unit error in calculating timings from ResourceLoadTiming API
+        https://bugs.webkit.org/show_bug.cgi?id=42473
+
+        The start and end offsets are already in milliseconds so they should not be multiplied by 1000.0 like requestTime.
+
+        No new tests because, for a yet unknown reason, the ResourceLoadTiming API is not populated in the chromium test shell like it is in full chromium. This means the test that would have caught this bug (fast/dom/webtiming.html) currently has its expectation set to FAIL.
+
+        * page/Timing.cpp:
+        (WebCore::Timing::domainLookupStart):
+        (WebCore::Timing::domainLookupEnd):
+        (WebCore::Timing::connectStart):
+        (WebCore::Timing::connectEnd):
+        (WebCore::Timing::requestStart):
+        (WebCore::Timing::requestEnd):
+        (WebCore::Timing::responseStart):
+
 2010-07-16  Anders Carlsson  <andersca at apple.com>
 
         Reviewed by David Levin.
diff --git a/WebCore/page/Timing.cpp b/WebCore/page/Timing.cpp
index 3423e76..e57e48a 100644
--- a/WebCore/page/Timing.cpp
+++ b/WebCore/page/Timing.cpp
@@ -113,7 +113,7 @@ unsigned long long Timing::domainLookupStart() const
     if (dnsStart < 0)
         return fetchStart();
 
-    return toIntegerMilliseconds(timing->requestTime + dnsStart);
+    return toIntegerMilliseconds(timing->requestTime) + dnsStart;
 }
 
 unsigned long long Timing::domainLookupEnd() const
@@ -128,7 +128,7 @@ unsigned long long Timing::domainLookupEnd() const
     if (dnsEnd < 0)
         return domainLookupStart();
 
-    return toIntegerMilliseconds(timing->requestTime + dnsEnd);
+    return toIntegerMilliseconds(timing->requestTime) + dnsEnd;
 }
 
 unsigned long long Timing::connectStart() const
@@ -143,7 +143,7 @@ unsigned long long Timing::connectStart() const
     if (connectStart < 0)
         return domainLookupEnd();
 
-    return toIntegerMilliseconds(timing->requestTime + connectStart);
+    return toIntegerMilliseconds(timing->requestTime) + connectStart;
 }
 
 unsigned long long Timing::connectEnd() const
@@ -158,7 +158,7 @@ unsigned long long Timing::connectEnd() const
     if (connectEnd < 0)
         return connectStart();
 
-    return toIntegerMilliseconds(timing->requestTime + connectEnd);
+    return toIntegerMilliseconds(timing->requestTime) + connectEnd;
 }
 
 unsigned long long Timing::requestStart() const
@@ -168,7 +168,7 @@ unsigned long long Timing::requestStart() const
         return 0;
 
     ASSERT(timing->sendStart >= 0);
-    return toIntegerMilliseconds(timing->requestTime + timing->sendStart);
+    return toIntegerMilliseconds(timing->requestTime) + timing->sendStart;
 }
 
 unsigned long long Timing::requestEnd() const
@@ -178,7 +178,7 @@ unsigned long long Timing::requestEnd() const
         return 0;
 
     ASSERT(timing->sendEnd >= 0);
-    return toIntegerMilliseconds(timing->requestTime + timing->sendEnd);
+    return toIntegerMilliseconds(timing->requestTime) + timing->sendEnd;
 }
 
 unsigned long long Timing::responseStart() const
@@ -194,7 +194,7 @@ unsigned long long Timing::responseStart() const
     // is basically equivalent. But for some responses, particularly those with
     // headers larger than a single packet, this time will be too late.
     ASSERT(timing->receiveHeadersEnd >= 0);
-    return toIntegerMilliseconds(timing->requestTime + timing->receiveHeadersEnd);
+    return toIntegerMilliseconds(timing->requestTime) + timing->receiveHeadersEnd;
 }
 
 unsigned long long Timing::responseEnd() const

-- 
WebKit Debian packaging