Use high precision timestamp for Event.timestamp

Source/core/events/Event.cpp

 /*
  * Copyright (C) 2001 Peter Kelly (pmk@post.com)
  * Copyright (C) 2001 Tobias Anton (anton@stud.fbi.fh-darmstadt.de)
  * Copyright (C) 2006 Samuel Weinig (sam.weinig@gmail.com)
  * Copyright (C) 2003, 2005, 2006, 2008 Apple Inc. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
@@ skipping 15 matching lines @@
 #include "core/dom/StaticNodeList.h"
 #include "core/events/EventDispatchMediator.h"
 #include "core/events/EventTarget.h"
 #include "core/frame/OriginsUsingFeatures.h"
 #include "core/frame/UseCounter.h"
 #include "core/svg/SVGElement.h"
 #include "wtf/CurrentTime.h"
 
 namespace blink {
 
+static const double millisPerSecond = 1000.0;
+
+static double monotonicTimeWithSafePrecision()

[Rick Byers, 2015/09/18 15:56:32]

Can you share this logic with the usage in PerformanceBase?  Eg. maybe
core/timing should be the place where such helpers live and Event just uses
those?

[majidvp, 2015/09/18 17:43:33]

Acknowledged.

+{
+    // Reduce the resolution to 5us similar to Performance.now() to prevent
+    // precise timing attacks.
+    static const double precision = 0.005 / millisPerSecond; // in seconds
+    return floor(monotonicallyIncreasingTime() / precision) * precision;
+}
+
 Event::Event()
     : Event("", false, false)
 {
 }
 
 Event::Event(const AtomicString& eventType, bool canBubbleArg, bool cancelableArg)
     : m_type(eventType)
     , m_canBubble(canBubbleArg)
     , m_cancelable(cancelableArg)
     , m_propagationStopped(false)
     , m_immediatePropagationStopped(false)
     , m_defaultPrevented(false)
     , m_defaultHandled(false)
     , m_cancelBubble(false)
     , m_isTrusted(false)
     , m_eventPhase(0)
     , m_currentTarget(nullptr)
     , m_createTime(convertSecondsToDOMTimeStamp(currentTime()))
-    , m_uiCreateTime(0)
+    , m_uiCreateTime(monotonicTimeWithSafePrecision())
 {
 }
 
 Event::Event(const AtomicString& eventType, const EventInit& initializer)
     : Event(eventType, initializer.bubbles(), initializer.cancelable())
 {
 }
 
 Event::~Event()
 {
@@ skipping 185 matching lines @@
     if (!m_currentTarget)
         return 0;
     Node* node = m_currentTarget->toNode();
     if (node && node->isSVGElement()) {
         if (SVGElement* svgElement = toSVGElement(node)->correspondingElement())
             return svgElement;
     }
     return m_currentTarget.get();
 }
 
+double Event::timeStamp() const
+{
+    double timeStamp = 0;
+    // TODO(majidvp): Get rid of m_createTime once the flag is enabled by default;
+    if (UNLIKELY(RuntimeEnabledFeatures::hiResEventTimeStampEnabled())) {
+        // Only expose monotonic time after changing its origin to its target
+        // document's time origin.
+        // TODO(majidvp): We do not reduce precision of user generated
+        // events here but perhaps we should to avoid any accidental leakage of
+        // hiResTime

[Rick Byers, 2015/09/18 16:17:29]

By user-generated you mean real events, not script-generated ones?  There are
indirect ways that script can create real events (eg. calling focus()).  Can we
be sure none of those are getting full precision timestamps?

Perhaps it's safest to just reduce all timestamps to 5us precision here (like
Performance.now) - I think that's plenty accurate for our input scenarios.

[majidvp, 2015/09/18 17:43:33]

User generated = real events. It will definitely be safest to reduce precision
before returning the value. That ensures there is no subtle paths where we might
expose actual time. I was not sure if that is accurate enough for real events
but if it is then I prefer that way.

[Rick Byers, 2015/09/21 15:44:37]

5us is really short, in practice the variability in input latency is much more
than that.  We typically pay attention to changes on the order of 50us or maybe
a little smaller ourselves.  Let's start with the safer option - we can always
try to relax it later if we decide it would be valuable.

+        if (m_target && m_target->toNode())
+            timeStamp =  m_target->toNode()->document().monotonicTimeToZeroBasedDocumentTime(m_uiCreateTime) * millisPerSecond;

[dtapuska, 2015/09/18 16:04:42]

How does this work when the m_currentNode and the m_targetNode are in different
documents? Rick tells me that shadow documents exist; and they will propagate
the same event across the trees.

[Rick Byers, 2015/09/18 16:17:29]

Event::m_uiCreateTime is poorly defined (and perhaps also poorly named). 
Perhaps worth at least improving comments there as part of this CL (i.e. what's
the timebase, explicitly say it's the time from the host OS - often called
"platform time").

[Rick Byers, 2015/09/18 16:17:29]

Does the conversion really have to be done based on the target node's document? 
That seems quite strange, and there are edge cases where it may not be what
you'd expect.  Also this will be broken for events dispatched to the window (not
all EventTarget's are Nodes).  Perhaps you can get the Window or LocalFrame of
the Event instead?  This is, I think, easy for UIEvent (stored in m_view), but
not so much for Event.

Maybe the real problem is that you're doing this conversion too late.  What if
we changed m_uiCreateTime (or added a new field) which was to be the exact
DOMHighPerformanceTimestamp value to be returned?  Then we'd do the time base
conversion when creating the Event in the first place (where we have some more
context)?  That would also avoid conversion back and forth for JS created events
(where the script is giving you the exact value that should later be returned).

[majidvp, 2015/09/18 17:43:33]

I agree that the target node's document may not be the best time reference given
what Dave pointed out.

We can definitely use LocalFrame or window where the event is created as a basis
for translation. It just needs some extra plumbing to make these available at
any place we create event

Another option is to use the time origin of the Window where Event.timeStamp is
accessed. This is pretty straightforward as binding can expose ScriptState. This
has the advantage that even if an event is passed across document, the value
returned by Event.timeStamp will be correct in relation to the context it is
being used. 



That would also avoid conversion back and forth for JS created events
I am not sure what you are referring here. We never take timestamp from script.
For script created events, their timestamp is be the monotonic  time at the time
of event creation. In any case, cost of changing the origin of a platform
monotonic time is negligible.

[Rick Byers, 2015/09/21 15:44:37]

Ah, sorry!  I assumed EventInitDict had a timestamp field, but it doesn't:
https://dom.spec.whatwg.org/#interface-event.  I'll file a spec issue to ask
about that.  But in the meantime, yes I agree the problem I was thinking of
doesn't actually exist.

+    } else {
+        timeStamp = m_createTime;
+    }
+
+    return timeStamp;
+}
+
+double Event::timeStampForPlatformInSeconds() const
+{
+    return RuntimeEnabledFeatures::hiResEventTimeStampEnabled() ? m_uiCreateTime : (m_createTime / millisPerSecond);
+}
+
 DEFINE_TRACE(Event)
 {
     visitor->trace(m_currentTarget);
     visitor->trace(m_target);
     visitor->trace(m_underlyingEvent);
     visitor->trace(m_eventPath);
 }
 
 } // namespace blink