Tests for requestIdleCallback deadline computation #31177
Conversation
| <script> | ||
|
|
||
| promise_test(async () => { | ||
| for (let i = 0; i < 10; ++i) { |
There was a problem hiding this comment.
Might be good to make it a constant
There was a problem hiding this comment.
Not sure if this is the right way to accomplish this.
The problem with deadlines is that they are "maximum" values, meaning that the UA can always decide to make them lower. So the tests check that they are below the cap, but that can happen by accident. By testing several time I try to reduce accidental passes, and catch cases where the deadline is greater than it should be.
There was a problem hiding this comment.
May be worthwhile to ask testing folks? (they used to be on the W3C #testing IRC channel, I'm not 100% sure that's still the case - @foolip may know)
There was a problem hiding this comment.
We're now on Matrix at https://app.element.io/#/room/%23wpt:matrix.org
For a case like this where it's possible to accidentally pass, this approach of trying many times to provoke the bug is a pattern I've seen before and I don't really have a better suggestion. To do better would require some additional control over the runtime, and usually that's not worth the effort to add.
It's an unfortunate fact that tests like this will be flaky failures when the bug exists. I don't know how to improve on that.
An elaborate comment on why it's like this and how to understand a failure would be good.
There was a problem hiding this comment.
Yea this is not easy because those deadlines are capped by the spec, but they can always be shorter, so testing several times can only reduce flakiness but not eliminate it, in case of a bug.
Added a comment
noamr
force-pushed
the
requestIdleCallback
branch
from
054221e
to
d3bc4b4
Compare
|
The corresponding HTML spec PR has been merged. |
Deadline should be: - capped at 50ms - capped at 1000/60 (~16ms) when there is a pending rAF callback - capped at the time of the next timeout - be updated when the above conditions change, during the callback itself See whatwg/html#7166
Co-authored-by: Philip Jägenstedt <philip@foolip.org>
noamr
force-pushed
the
requestIdleCallback
branch
from
d3bc4b4
to
ca91ea1
Compare
…s#31177) * Tests for requestIdleCallback deadline computation Deadline should be: - capped at 50ms - capped at 1000/60 (~16ms) when there is a pending rAF callback - capped at the time of the next timeout - be updated when the above conditions change, during the callback itself See whatwg/html#7166 Co-authored-by: Philip Jägenstedt <philip@foolip.org>
Deadline should be:
See whatwg/html#7166