This failure has not been filed yet, happened couple of times on try server. 20:31:23 INFO - 600 INFO TEST-UNEXPECTED-FAIL | dom/tests/mochitest/gamepad/test_gamepad.html | undefined assertion name 20:31:23 INFO - connecthandler@dom/tests/mochitest/gamepad/test_gamepad.html:22:1 20:31:23 INFO - @dom/tests/mochitest/gamepad/test_gamepad.html:20:1 https://treeherder.mozilla.org/logviewer.html#?job_id=9937986&repo=try https://treeherder.mozilla.org/logviewer.html#?job_id=9902536&repo=try https://treeherder.mozilla.org/logviewer.html#?job_id=9894967&repo=try

The failure line is : ok(e.gamepad.timestamp <= performance.now()); The timestamp of the gamepad seems somehow wrong there.

I am guessing the failure reason is http://hg.mozilla.org/mozilla-central/rev/48ae8b5e62ab I do not have the permission to see bug 1167489 and bug 1153672 unfortunately. Should we do the same thing in Gamepad::UpdateTimestamp(), or modify the failure test? I am confident that bug 1182285 is caused by the same reason.

Indeed, if we're chopping off fractions of 5us from the rhs, then the inequality could test false. And yes, sounds like we should similarly clamp the gamepad timestamp. And add an actual assertion name to that ok() call.

Uses Performance::Now() instead of conversion with TimeStampToDOMHighRes().

Comment on attachment 8640971 [details] [diff] [review] A patch suggedted by comment #3 Nice! r=me

Thanks! https://treeherder.mozilla.org/#/jobs?repo=try&revision=4fb9d06f1342

Is this worth backporting to 41?

Probably, yes.

Comment on attachment 8640971 [details] [diff] [review] A patch suggedted by comment #3 Approval Request Comment [Feature/regressing bug #]: This is a relevant bug of bug 1167489 and bug 1153672. [User impact if declined]: Exposed timing attacks [Describe test coverage new/current, TreeHerder]: There were two tests which had been failed intermittently. This patch fixed those. [Risks and why]: low [String/UUID change made/needed]: none

Comment on attachment 8640971 [details] [diff] [review] A patch suggedted by comment #3 Let's uplift to Aurora if this helps fix intermittent test failure. Fix seems straightforward and has been in m-c for a few days so should be stable.