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

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](https://docs.google.com/spreadsheets/d/14ZO8Xfkn4GbGr11cWEgV47xVhXQmhQSswT1IjpCtYRg/edit#gid=0).

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

It also seems that this change breaks at least some part of YouTube, which is still not fixed as of 3 days ago, per [comment 24 on chrome bug 574514](https://code.google.com/p/chromium/issues/detail?id=574514#c24):

> Yes, I am the right owner to fix the test. This test is to ensure that browsers don't break YouTube. I'm going to wait until YouTube fixes their code before I fix the test. As of right now, the event.timeStamp epoch is still a requirement for YouTube.

Even thought it didn't detect these cases, the number of cases detected by simplistic static analysis still exceeds the speculative threshold of 0.01.

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.

Timing-related bugs are subtle and hard to track down, and this particular change will affect old sites which aren't even maintained anymore. Given that a number of high-profile breakages have already been reported, and that it doesn't manifest as a hard error, I'm having a hard time understanding why the experiment has not conclusively failed.

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