When a paint worklet thread takes too long, we would like to move on,
since we have a ~16ms budget for rendering @60fps. At the moment, there
is no provision in the paintworklet spec to signal such timeouts to the
developer. ajeffrey opened an [issue][1] for this, but it got punted to
v2 of the spec. Hence we are silently timing out unresponsive paint
scripts.
The timeout value is chosen to be 10ms by default, and can be overridden
by setting the `dom.worklet.timeout_ms` pref.
In the absence of such a timeout, the reftest in this commit would fail
by timing out the testrunner itself, since the paint script never
returns. From my discussions with ajeffrey, this should do until we spec
out a way to signal timeouts to the script developer.
Since we did not have a better way to trigger a timeout than a busy
waiting loop (which would hog one core of the test machine until the
timeout was reached), we decided to implement a test only blocking
sleep, available to the PaintWorkletGlobalScope. Since
`dom.worklet.enabled` enables worklets in general, we also decided to
have another pref `dom.worklet.blockingsleep.enabled`, which, in
addition to `dom.worklet.enabled`, would be required for the blocking
sleep to be available.
This fixes#17370.
[1]: https://github.com/w3c/css-houdini-drafts/issues/507
