Re: [dom] High resolution timing for events (#23)

> Also, the analysis:

> > e.timeStamp - value
> > value - e.timeStamp
> That does not cover any of the reported cases, including Angular's use case.
No it does not.

> > ...and I have assumed breakage if the usage was not obvious.
> None of the reported cases hard errors and only break in ways that cannot be easily detected.

Sorry, if I was not clear. In this case I meant that if I was not fairly sure about "o.timeStamp - value" usage I assumed it gets broken (i.e., o.timeStamp is an event value and values is a date). To be honest based on the codes I check during the process most of the time this pattern end up being safe, e.g., either timeStamp is coming from Date.now() or value is another timeStamp but I erred on the side of over estimating the breakage in this case.

> While 0.01% sounds like a small number, it means that it affects 1 / 10,000 sites. The static analysis also breaks out "bugsnag". Bugsnag is an error reporting tool that the static analysis suggests accounts for another 0.01% on its own. Again, this is just a case that happened to be detected using the static analysis.

In fact, I think 0.01% of the issue being attributed to *bugsnag* is a promising sign (not to discount other issues). Their usage is essentially what I would categorize under "clearly survivable" category. They usage pattern is to compute a ```millisecondsAgo``` for the last event which is reported as part of the metadata for when an error is reported. There is no user-facing impact, and their code was reporting invalid values for Firefox that apparently no one noticed. This is simple to fix and also has also a backend solution. This is the best possible breakage and they seem to be [happy](https://github.com/bugsnag/bugsnag-js/issues/130#issuecomment-179369700) about the change.

> It's worth reiterating that the breakage in Angular (which was in code in the main angular.js), would have been detected by the already-done static analysis.

I think you meant would *NOT* have been detected.

> It also would not have detected the bug that @chancancode and I found in our demo code (we stored e.timestamp in an object).

Correct.

So the simplistic analysis over counts in some cases and under counts in others. Which is why I don't like to rely too much on it. Just to get a sense of things in combination with other evidence.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/23#issuecomment-181630562