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

@birtles:

> @wycats: @bzbarsky, @annevk and I discussed this in February this year and I think @bzbarsky in particular had a preference for adding another eventTime or time member given the compatibility concerns.

@majido:

> I wish this was shared earlier. All other signals so far has been that Firefox is on-board with
the plan to experiment and ship if we don't find a non-trivial compat issues.

**TLDR: By February, multiple Mozilla engineers had become increasingly uncomfortable with the change and repeatedly described it as not-web-compatible.**

The concerns about web compatibility were repeatedly shared earlier, around the same Feburary timeframe. Based on the threads you and @RByers participated in, I'm not sure where you are getting the idea that Firefox was still on board with the plan.

---

On December 10, in a linked issue from this thread:

> We have a web compat issue reported in bug 1231619.  See bug 1231619 comment 3.

In the referenced bug [bug 1231619](https://bugzilla.mozilla.org/show_bug.cgi?id=1231619):

> So this is an actual web compat problem.

At this point, Mozilla engineers were starting to think that there might be a web compat issue.

@RByers replied:

> Personally I don't think this example alone should block our plans to ship DOM highRes event timestamps.

This is the first of many comments by Chrome engineers waving away reports of web compatibilities.

@birtles:

> Clearing needinfo since it's clearly a Web compat problem.

@dbaron:

> Web compatibility issue with a well-known library that we need to avoid shipping.

@RByers then tried to persuade Firefox to ship anyway. David Baron replied:

> Shipping a feature where a developer getting it wrong means their page is intermittently broken on a small percentage of machines seems pretty bad.  Seems like people are likely to get that wrong forever.  It seems better to actually go through a more-breaking change once.

Again, Mozilla engineers are becoming increasingly concerned, contrary to the idea that they were still just fine with the plan.

You replied, arguing that since Angular fixed the issue, we're clear to ship:

> FYI, Angular has fixed the issue[1] and it is expected to be in their upcoming 1.5 release.

Around this time, @chancancode and I noticed that this problem broke one of our demos. @stefanpenner (another Ember developer) [reported the "bug" to Chrome](https://bugs.chromium.org/p/chromium/issues/detail?id=574249#c3), and @chancancode elaborated:

> Again, once we identified the problem, it was an easy fix, but I'm just quite worried about web-compat given the subtle nature of this difference.

@majido replied:

> This is indeed the new desired behaviour which is currently planned to be launched on M49. See: https://www.chromestatus.com/features/5523910145605632

Again, no major concern that there might be a web compatibility issue, but rather "damn the torpedoes; full speed ahead!" and a suggestion that we should work harder to fix the problem on our end. We were happy to do so, but concerned about the web compat issue.

Since we quickly discovered the Angular thread and noticed that @majido and @RByers were on it, we moved the conversation there.

> I believe there is a more general form of this problem that is likely to break other sites. 

You replied:

> I prefer that we try to use monotonic time first.

@chancancode replied with [a very detailed comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c19) explaining our concerns.

At this point, it appears that bz became increasingly concerned:

> Fwiw, I generally agree with comment 19.

Around the same time that @chancancode and I reported the bug, YouTube engineers discovered [a bug in their test suite](https://bugs.chromium.org/p/chromium/issues/detail?id=574514&q=event.timestamp&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified).

The code in question was relatively simple:

```js
var last = Date.now();
// later
video.addEventListener('timeupdate', function(e) {
  runner.checkGE(e.timeStamp, last, 'event.timeStamp');
  last = e.timeStamp;
});
```

In other words a classic example of wanting to compare an `e.timeStamp` against some earlier fixed time.

The YouTube engineer [originally surmised](https://bugs.chromium.org/p/chromium/issues/detail?id=574514#c9):

> This is a browser bug.

At this point, with the breakage in Angular, the report we had of a bug in a demo, and this bug by YouTube, it should have become clear that this change was not web-compatible. Instead of easing off and trying to learn more, the Chrome team pressed ahead, sure that they could just wish the problem away.

@majido told the YouTube engineer:

> Sure, but there is a planned changed for DOM spec: https://github.com/whatwg/dom/issues/23
> And Chrome M50 will reflect this change. As #16 pointed out the spec update is pending us successful shipment in Chrome.

The engineer replied:

> 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.

Again, the fact that YouTube made this "mistake" should have been enough evidence to ease off and get more information.

Now that Chrome has shipped, you're saying things like:

> On YouTube case: They had an existing workaround for Firefox edgecases which works
well for Chrome recent changes as well. So they haven't done any modification in response to a breakage. So there was no modification or impact.

I can't see the YouTube source code, but after Chrome shipped, YouTube **did** [update the test in question](https://github.com/youtube/js_mse_eme/commit/11ba872749540c17ef7285ace0fba383556a867b#diff-9453484b98c90636a1c71b95507ab2d1) to stop relying on `e.timeStamp` being directly comparable to `Date.now()` with the message "Updated EventTimestamp test on Tip to be more spec compliant and Chrome compliant".

I'm not sure where you got the idea that everyone was just fine with moving ahead, but it does seem clear that you deeply **wished** for that to be true.

It continues to be the case that textual analysis is very unlikely to identify most sources of this bug, and that incidents of the bug are likely to be under-reported (people will believe that the web is janky, rather than that there is a bug in the content they're looking at).

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/23#issuecomment-215312562