Use high precision timestamp for Event.timestamp

Source/core/events/Event.idl

Index: Source/core/events/Event.idl
diff --git a/Source/core/events/Event.idl b/Source/core/events/Event.idl
index 07398122bdfe586dfe239ebb2290f36e479dab37..c95a45eadd8c6f02b9f80d7a59a64dfdee8c369d 100644
--- a/Source/core/events/Event.idl
+++ b/Source/core/events/Event.idl
@@ -44,7 +44,7 @@
     readonly attribute boolean defaultPrevented;
 
     [RuntimeEnabled=TrustedEvents, Unforgeable] readonly attribute boolean isTrusted;
-    readonly attribute DOMTimeStamp timeStamp;
+    readonly attribute DOMHighResTimeStamp timeStamp;

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

Are the semantics of this unchanged since it is now a double; wrt NaN
initialization of a timestamp?

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

Right, we need to make sure that this type change isn't visible to the web at
all (at least until we make the RuntimeEnabledFeature stable).  Eg. JS created
events with non-integer timestamps should have their timestamp coerced when the
feature is disabled in the exact same way it is before your code.  We'll
probably want some tests for this (that pass before and after your CL).

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

Good point. I will make sure this is covered in my tests.

 
     // FIXME: initEvent()'s arguments should not be optional.
     [Measure] void initEvent([Default=Undefined] optional DOMString type,