Re: [whatwg] Proposal: Event.creationTime

2014-05-14 Thread Glenn Maynard
On Thu, May 8, 2014 at 2:33 AM, Brian Birtles bbirt...@mozilla.com wrote:

 (2014/05/08 0:49), Glenn Maynard wrote:

 Can you remind me why this shouldn't just use real time, eg. using the
 Unix
 epoch as the time base?  It was some privacy concern, but I can't think of
 any privacy argument for giving high-resolution event timestamps in units
 that are this limited and awkward.


 [1] has some justification for why we don't use 1970. As does [2].
 I'm not sure what the privacy concerns raised in the past were with
 regards to 1970.


Okay, I remember.  It's not that using the epoch here is itself a privacy
issue, it's that the solutions to the monotonicity problem introduce
privacy issues: if you add a global base time that isn't per-origin, that's
a tracking vector.

Maybe a solution would be to make DOMHighResTimeStamp structured clonable
(or a wrapper class, since the type itself is just double).  If you post a
timestamp to another thread, it arrives in that thread's own time base.
That way, each thread can always calculate precise deltas between two
timestamps, without exposing the actual time base.  (You still can't send
it to a server, but that's an inherent problem for a timer on a monotonic
clock.)

If you treat Date.now() as your global clock, you can roughly convert
 between different performance timelines but with the caveat that you lose
 precision and are vulnerable to system clock adjustments. (There is
 actually a method defined for converting between timelines in Web
 Animations but the plan is to remove it.)


That would defeat the purpose of using high-resolution timers in the first
place.

-- 
Glenn Maynard


Re: [whatwg] Proposal: Event.creationTime

2014-05-08 Thread Brian Birtles

(2014/05/08 0:49), Glenn Maynard wrote:

Can you remind me why this shouldn't just use real time, eg. using the Unix
epoch as the time base?  It was some privacy concern, but I can't think of
any privacy argument for giving high-resolution event timestamps in units
that are this limited and awkward.


[1] has some justification for why we don't use 1970. As does [2].
I'm not sure what the privacy concerns raised in the past were with 
regards to 1970.


If you treat Date.now() as your global clock, you can roughly convert 
between different performance timelines but with the caveat that you 
lose precision and are vulnerable to system clock adjustments. (There is 
actually a method defined for converting between timelines in Web 
Animations but the plan is to remove it.)


Best regards,

Brian

[1] 
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html#introduction

[2] http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0031.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2


Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Adam Barth
Can we just change timeStamp to be a DOMHighResTimeStamp rather than
introducing a redundant property?

Adam



On Tue, May 6, 2014 at 10:51 PM, Brian Birtles bbirt...@mozilla.com wrote:

 Hi,

 Gecko's implementation of Event.timeStamp does not conform to the spec[1]
 since it reports the number of milliseconds since system start rather than
 00:00:00 UTC on 1 January 1970. This is tracked as Mozilla bug 77992 [2].
 DOM Level 2 allowed this[3] but the spec has since changed.

 One reason for not updating to match the spec has been concern about using
 a non-monotonic clock as a time source. This can lead to bugs when the
 system clock is adjusted.

 Now that we have a DOMHighResTimeStamp that provides a monotonically
 increasing time, I propose we add it to the Event interface.[4]

 This time is measured from navigationStart which removes some of the
 security concerns raised regarding using system start.[5] navigationStart
 is also the point of reference being using for Performance.now(),
 requestAnimationFrame and Web Animations.

 As for use cases for event timestamps, apparently Youtube uses the
 timeStamp on progress events to estimate download bandwidth. Another use
 case is that of SMIL which seems to want to overload the timestamp from
 being strictly creation time to when the event *should* have been created
 in order to avoid synchronization slew.[6]

 Proposal:

   partial interface Event {
 readonly attribute DOMHighResTimeStamp creationTime;
   };

 (Alternative naming suggestions are obviously most welcome.)

 Semantics are as with 'timeStamp' but based on navigationStart.

 Given that 'timeStamp' is currently implemented inconsistently, it might
 be possible to eventually deprecate it.

 Best regards,

 Brian

 [1] http://dom.spec.whatwg.org/#dom-event-timestamp
 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=77992
 [3] http://www.w3.org/TR/DOM-Level-2-Events/events.html#
 Events-Event-timeStamp
 [4] http://www.w3.org/TR/hr-time/
 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2
 [6] http://www.w3.org/TR/SMIL/smil-timing.html#q135



Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Boris Zbarsky

On 5/7/14, 1:51 AM, Brian Birtles wrote:

This time is measured from navigationStart


It's probably better to say that it's measured from the same 0 point as 
performance.now(), since there is no navigationStart in workers but 
there are events there.


-Boris


Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread L. David Baron
On Tuesday 2014-05-06 23:00 -0700, Adam Barth wrote:
 Can we just change timeStamp to be a DOMHighResTimeStamp rather than
 introducing a redundant property?

I'd certainly be happy to see such a change; I argued that
Event.timeStamp be based on a monotonic clock previously, in:
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0071.html
http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0098.html

I'm not sure if there would be compatibility problems from changing
from unsigned long long [1] to double [2], though.  The type
change seems like the biggest compatibility risk in content that
works today across browsers, given that browsers on whether the time
is epoch-based or monotonic.

I don't have any data on how or how often Event.timeStamp is used,
though.

-David

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-DOMTimeStamp
[2] http://www.w3.org/TR/hr-time/#sec-DOMHighResTimeStamp

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Anne van Kesteren
On Wed, May 7, 2014 at 7:00 AM, Adam Barth w...@adambarth.com wrote:
 Can we just change timeStamp to be a DOMHighResTimeStamp rather than
 introducing a redundant property?

http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg8
is the previous thread on this topic. In that thread bz pointed out
that changing Date.now() to return sub-milliseconds as an experiment
failed.

If people want to do the experiment for Event.prototype.timeStamp I'd
be happy with that.

Is there a good reference somewhere for what the time would be relative to?


(I previously had a problem with doing this in DOM as it would depend
on page load time which is defined by HTML, but I have since accepted
that HTML and DOM are intertwined.)


-- 
http://annevankesteren.nl/


Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Boris Zbarsky

On 5/7/14, 6:43 AM, Anne van Kesteren wrote:

Is there a good reference somewhere for what the time would be relative to?


https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview.html#sec-time-origin 
seems like the right thing.


-Boris


Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Adam Barth
On Wed, May 7, 2014 at 3:43 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 7, 2014 at 7:00 AM, Adam Barth w...@adambarth.com wrote:
  Can we just change timeStamp to be a DOMHighResTimeStamp rather than
  introducing a redundant property?

 http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg8
 is the previous thread on this topic. In that thread bz pointed out
 that changing Date.now() to return sub-milliseconds as an experiment
 failed.

 If people want to do the experiment for Event.prototype.timeStamp I'd
 be happy with that.


It seems worth experimenting with.  If the experiment fails, we can try
another approach.

Adam


Is there a good reference somewhere for what the time would be relative to?

 (I previously had a problem with doing this in DOM as it would depend
 on page load time which is defined by HTML, but I have since accepted
 that HTML and DOM are intertwined.)


 --
 http://annevankesteren.nl/



Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Anne van Kesteren
On Wed, May 7, 2014 at 4:34 PM, Adam Barth w...@adambarth.com wrote:
 It seems worth experimenting with.  If the experiment fails, we can try
 another approach.

Fair enough, once it succeeds I'll update the specification.


-- 
http://annevankesteren.nl/


Re: [whatwg] Proposal: Event.creationTime

2014-05-07 Thread Glenn Maynard
On Wed, May 7, 2014 at 10:08 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 5/7/14, 6:43 AM, Anne van Kesteren wrote:

 Is there a good reference somewhere for what the time would be relative
 to?


 https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview.
 html#sec-time-origin seems like the right thing.


This seems to make it impossible to get the time of an event in real time,
so you can compare it to external events or send it to shared workers.

Can you remind me why this shouldn't just use real time, eg. using the Unix
epoch as the time base?  It was some privacy concern, but I can't think of
any privacy argument for giving high-resolution event timestamps in units
that are this limited and awkward.

-- 
Glenn Maynard