Timer initialization steps for repeating timers does not match UA behavior

[shaseley]

For setInterval(), in the "timer initialization steps", "run steps after timeout" is invoked with the original timeout after the callback completes (step 9.5), but UAs schedule subsequent iterations such that next_start_time = previous_start_time + interval.

For example, if you have a setInterval(,50) where each iteration is 25ms, I observe there's ~50ms between iteration start times on FF, Safari, and Chrome (Chrome fires early sometimes, but that's a separate issue), whereas per spec I think this should output ~75ms between iterations (25ms callback + 50ms timeout).

My reading of the Gecko, WebKit, and Blink code matches what I'm seeing, and I think updating the spec to match the UA behavior would make sense. Happy to draft a PR assuming my reading is correct here and folks agree with the change.

[annevk]

That sounds reasonable to me, although I haven't checked the code. Presumably we do need to be a little careful when the code runs for longer than the interval, but that seems manageable.

cc @smaug----

[Kaiido]

I believe this is a duplicate of #3151 which also tried to have Chrome's "drift-free" implementation standardized.