Event-timestamp-high-resolution.html is almost permafail since the resolution of performance.now() was changed to 20us

RESOLVED DUPLICATE of bug 1387894

Status

()

enhancement
P3
normal
RESOLVED DUPLICATE of bug 1387894
2 years ago
7 months ago

People

(Reporter: RyanVM, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox57 disabled, firefox58 disabled, firefox59 disabled)

Details

In bug 1427870, we had to change the resolution of performance.now() from 5us to 20us. This is causing Event-timestamp-high-resolution.html permafails now as a result. I'm going to annotate my way to victory for the time-being since this is time-sensitive, but given that this change is being shipped across all vendors, the test will probably need some sort of longer-term fix as well.

https://treeherder.mozilla.org/logviewer.html#?job_id=153979112&repo=mozilla-release
Not that this test was very reliable to begin with. See bug 1387894.
See Also: → 1387894
I pushed the annotation update to m-c and will soon do the same for Beta & Release:
https://hg.mozilla.org/mozilla-central/rev/25d2937fa7dd7f7a697c4ba053959f4cf4416af6

However, I fully expect to also file a new intermittent-failure bug for unexpected passes since this isn't 100% permafailing. But I think it'll still be more manageable than the current failures.
Summary: Event-timestamp-high-resolution.html permafails with the resolution of performance.now() changed to 20us → Event-timestamp-high-resolution.html is almost permafail since the resolution of performance.now() was changed to 20us
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/mozilla-central/rev/7d81f423c7ff
Disable Event-timestamp-high-resolution.html for frequent failures. r+a=bustage
The change in comment 2 didn't work because wpt treats global annotations as separate from subtest annotations :(. Since the failures happen unpredictably in various subtests, I don't see any other option besides disabling the test on opt builds for now, which is what the commit in comment 3 does.
baku, can you take a look here? Maybe Andreas can help you.

bkelly brought up the good question of whether or not we should raise a spec issue about changing the resolution to be 20 μs.
Flags: needinfo?(amarchesini)
Flags: needinfo?(afarre)
(In reply to Andrew Overholt [:overholt] from comment #6)
> bkelly brought up the good question of whether or not we should raise a spec
> issue about changing the resolution to be 20 μs.

20ms is a stopgap. I think any spec changes would be considerably more expansive of that, and would aim to frustrate or prevent high resolution timers from being constructed from any browser feature.

*Alternately* we could consider the notion that providing high resolution timing information (either in javascript or to user-mode code via rtdsc) is a perfectly acceptable thing to do. It sounds quite reasonable right? The implication of such a declaration is that *any* software or hardware mechanism that allows privilege boundary bypasses is a bug, from microcode in SPECTRE to non-constant time animation rendering to non-cache neutral crypto algorithms to...
FYI, Spectre and Meltdown should be discussed tomorrow during webperf wg conf call
 https://lists.w3.org/Archives/Public/public-web-perf/2018Jan/0001.html
Priority: -- → P3
Is this issue relevant any longer since we're doing Fission?
Flags: needinfo?(afarre)
Fixing Bug 1387894 should resolve it.
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1387894
Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.