Fix mainThreadBusy intermittent failures in event-timing tests due to timer precision rounding

[canova]

Test List

More of a test util function (mainThreadBusy) used by multiple tests: event-timing/resources/event-timing-test-utils.js
Main test that's affected by this is: event-timing/duration-with-target-low.html

Rationale

Currently event timing tests have the mainThreadBusy function, which is used to block the main thread for a specific duration. It's used by a lot of tests.

We were investigating some intermittent timeouts/failures in Firefox (in bug 2011967) and realized that some tests were actually waiting less than the provided duration.

The issue is that mainThreadBusy relies on performance.now() for timing, but Firefox rounds these timestamps to 1ms precision for privacy protection against timing attacks (e.g., Spectre). When the test requests a 300ms busy-wait (for example in event-timing/duration-with-target-low.html), the loop can exit early (~299ms) when timestamps round unfavorably. For example, if the start timestamp rounds down and the end timestamp rounds up as well, we might get only 299ms of actual blocking time.

This causes intermittent failures because the busy-wait duration doesn't consistently meet the required threshold. We observed about a 10% failure rate in affected tests.

Proposed Fix

We propose adding a 2ms overshoot to the mainThreadBusy function to account for timer precision rounding and jitter (example commit):

function mainThreadBusy(ms) {
  const target = performance.now() + ms + 2;
  while (performance.now() < target);
}

The 2ms buffer ensures that even with unfavorable rounding, the function will block for at least the requested duration across all browsers.

1ms would be sufficient to account for timer precision rounding alone, but we use 2ms for good measure to also allow for any possible similar issues from "jitter" (intentional anti-fingerprinting randomness introduced into performance.now() values, which may make them lie by up to 1ms, while still keeping them monotonically increasing).

This change is conservative and doesn't negatively impact test behavior. I tested the change in both Chrome and Safari, and they continue to pass all tests with this modification, and it eliminates the intermittent failures we were seeing in Firefox.

PR that implements the proposal is in web-platform-tests/wpt#57314.

[canova]

Hi @mmocny, @francovs, what do you think about my proposal above? I tested locally and don't see a difference in the test results in both Chrome and Safari.

[mmocny]

I think that's fine. Alternative would be to change the call sites to stop being so specific about timing requirements (most call sites are from common help utils)... but unfortunately I do see that a lot of tests manually call this and manually set specific duration expectations (and some already add a variable amount of "wiggle room").

[canova]

Thanks for your input @mmocny! Yeah, I thought about that alternative too, but it turned out to be more complicated than this solution since it touches a lot of tests. This solution looked like the least invasive one.

[dholbert]

Hi @mmocny, @francovs, what do you think about my proposal above?

Perhaps @nt1m or @gsnedders could sign off for WebKit if @francovs isn't available.

(tl;dr the proposed change here is just to wait 2 extra milliseconds in a performance.now()-based "block for N milliseconds" utility-function that some event-timing tests use, so that its users have a better guarantee that at least N milliseconds have indeed passed. More notes above and also in the patch.)

[francovs]

Sounds fine to me as well. Adding slop to mainThreadBusy() while keeping the timings used in tests tight feels correct.