Use a monotonic clock (TimeTicks) to report network times to WebCore.

webkit/glue/resource_loader_bridge.h

Index: webkit/glue/resource_loader_bridge.h
diff --git a/webkit/glue/resource_loader_bridge.h b/webkit/glue/resource_loader_bridge.h
index dcc86f4a5a6713baeea637967fc5ce9846fb504f..9872b8418d46183527a9eeda368a61e362f0047e 100644
--- a/webkit/glue/resource_loader_bridge.h
+++ b/webkit/glue/resource_loader_bridge.h
@@ -51,8 +51,11 @@ struct ResourceLoadTimingInfo {
   ResourceLoadTimingInfo();
   ~ResourceLoadTimingInfo();
 
-  // All the values in this struct are given as offsets in milliseconds wrt
-  // this base time.
+  // All the values in this struct are given as offsets in ticks wrt
+  // this base tick count.
+  int64 base_ticks;

[pfeldman, 2011/08/09 18:15:22]

To clarify: you only need this to be able to compare it against finishTime when
you start sending it as ticks?

[James Simonsen, 2011/08/09 18:31:51]

Oops. In my haste, I uploaded a slightly older branch. Maybe now it's clearer.

Let me try to explain my initial idea again.

1. WebCore records currentTime() and monotonicallyIncreasingTime() (aka
TimeTicks) when the loader is created. These are the reference* times.

2. Chrome's network stack records base_ticks. All of the times in
WebURLLoadTiming are relative to that, including a new responseEnd.

3. When a Javascript user wants to know when the end of the document is
received, we need to convert the monotonic time back to a wall time. The
calculation is:

referenceTime + (base_ticks - monotonicReferenceTime) + responseEnd

I'm proposing finishTime not be used at all for the above use case. I'd love to
convert inspector over to using responseEnd too.

The idea of a Document's reference time comes from the Navigation Timing spec
and is implemented in IE. Someone from Mozilla mentioned they also have a
similar concept.

+
+  // The value of Time::Now() when base_ticks was set.
   base::Time base_time;
 
   // The time that proxy processing started. For requests with no proxy phase,