Problem: The abortsignal-timeout.html test was (still) intermittently
failing under CI — printing “…at least 10 milliseconds: false”.
Cause: The test asserts AbortSignal.timeout(10) fired >= 10ms later,
measured as a wall-clock time of performance.now() delta + 1ms fudge.
But that involves timings from two *different* clocks: performance.now()
uses CLOCK_MONOTONIC, while the timeout timer is armed and fired against
CLOCK_MONOTONIC_COARSE (the event-loop clock) — which is quantized to
the kernel tick, and which lags the precise clock by up to a tick. Thus,
a 10ms coarse-scheduled timeout can fall short of 10ms of precise time
by up to one tick. So what was likely happening is: When that shortfall
exceeds the 1ms fudge (coarse-tick kernels, or ticks delayed under CI
load), the delta landed under 10ms. The 1ms fudge added by 6fa32fbf69
narrowed but never closed the race — because the check gates on host
timer/clock precision, rather than on AbortSignal behavior.
Fix: Drop the wall-clock timing assertion. Keep the deterministic checks
that actually exercise AbortSignal.timeout: The abort fires, its
reason is TimeoutError, and the event is trusted. And add a synchronous
check that the signal isn’t aborted immediately after creation – which
confirms the abort is deferred, without racing the clock.
bbfa1ca7ae