Timeout Timing In Background Chrome Tab Is Inconsistent

[admiralbolt]

When using timeout or rawTimeout in a background chrome tab the actual timing result seems to vary. Chrome does seem to throttle to a maximum of 1 call / second when in background tabs, but it seems like the actual timeout call itself takes twice as long for values above 1000 as well. Pretty easy test:

let prev_date = new Date();
yield timeout(1000);
console.log(new Date() - prev_date);

Watching this loop while the chrome tab is focused spits out 1000 milliseconds diff every time. However, switching to a different tab makes the timeout take 2000 milliseconds instead.

[maxfierke]

@admiralbolt You're right on it, this is a common optimization done by browsers to reduce work done by inactive tabs. As such, we don't have much control over it within ember-concurrency

You can read more about some of the throttling behavior here https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout#Reasons_for_delays_longer_than_specified

The reason for the doubling is likely due to that internally in some cases, there is another setTimeout used for scheduling, depending on the state of the runloop. This will likely improve w/ ember-concurrency v2 which only uses the runloop/micro-tasks queue for scheduling, so it will perhaps be a bit more dependable.