Use high precision timestamp for Event.timestamp

third_party/WebKit/Source/core/dom/Document.cpp

Index: third_party/WebKit/Source/core/dom/Document.cpp
diff --git a/third_party/WebKit/Source/core/dom/Document.cpp b/third_party/WebKit/Source/core/dom/Document.cpp
index dff02f7249fa660d7e136ddbdfd24c7ad473be35..b2f59fae88e33044b42551e4819d45603137f354 100644
--- a/third_party/WebKit/Source/core/dom/Document.cpp
+++ b/third_party/WebKit/Source/core/dom/Document.cpp
@@ -5120,6 +5120,14 @@ void Document::pluginLoadingTimerFired(Timer<Document>*)
     updateLayout();
 }
 
+double Document::monotonicTimeToZeroBasedDocumentTime(double monotonicTime) const
+{
+    if (!loader())
+        return 0;

[Rick Byers, 2015/09/25 17:29:33]

any idea when this would happen in practice?  Just wondering what bugs might
results.  Is there precedent for using invalid timestamps in such situations? 
Ideally we'd be able to ASSERT that this doesn't happen.

[majidvp, 2015/09/29 14:21:31]

I imagine this can happen if for example one creates a document with
document.implementation.createHTMLDocument().

I changed the implementation so that it uses the same fallback logic as
performance::now() in such cases (i.e., time origin = 0). This will ensure we
are always consistent with performance::now() and timestamps remain relatively
valid.

I am not so sure about the correctness of the performance::now() fallback but
logged a separate ticket for that
https://code.google.com/p/chromium/issues/detail?id=536959 

+
+    return loader()->timing().monotonicTimeToZeroBasedDocumentTime(monotonicTime);
+}
+
 ScriptedAnimationController& Document::ensureScriptedAnimationController()
 {
     if (!m_scriptedAnimationController) {