[Feature Request] An option to have consistent timeout in unfocused windows using web workers

[Piratux]

Is your feature request related to a problem? Please describe.
I am using browser to run an app, where browser most of the time stays unfocused. My app uses timeouts, and I require those timeouts to not be throttled by unfocused browser. When browser is unfocused, even 1 second timeout may never finish, until browser gets focused again.

For this purpose, I use setTimeout from worker-timers.

However, I run into a pattern where I sometimes require "wait until" pattern to be used. For that, I've chosen, to use this library. But unfortunately this library doesn't have an option to run timeouts using web workers.

Describe the solution you'd like
An option to indicate, to run timeouts (both options.timeout and options.intervalBetweenAttempts) using web workers. Perhaps an option such as passing options.useWorkerTimeout: boolean could be used, where false (default value) would indicate to run native timeout, and true would indicate to run using worker timeout.

As for implementation, you could choose to use worker-timers library.

Describe alternatives you've considered
Not using this library, and implementing waitUntil myself to use web worker timeouts. However, I thought someone else may benefit if this was part of the library.

[devlato]

@Piratux thanks for reporting an idea — could you tell me more about the use case you're trying to solve with web worker-based timers?

[devlato]

Thanks for raising this and for the detailed explanation!

I agree that background tab throttling is painful, and that using Web Workers (or libraries like worker-timers) can sometimes reduce timer drift when the tab is inactive.

However, modern browsers can still throttle or even completely suspend background pages and their workers under certain conditions (e.g. long-hidden tabs, battery/memory pressure). So unfortunately the library cannot guarantee “non-throttled” timers just by switching to worker-based timeouts.

Instead of hard-coding a dependency on worker-timers, I’m leaning towards a more general solution: allowing callers to inject their own timer implementation. For example, something like:

interface TimerApi {
  setTimeout(fn: () => void, ms: number): any;
  clearTimeout(id: any): void;
}

waitUntil(predicate, {
  timeout,
  intervalBetweenAttempts,
  timers, // optional: defaults to window.setTimeout / clearTimeout
});

This would let you plug in worker-timers (or any other scheduling mechanism) on your side, without forcing it on every consumer and without complicating SSR / non-browser usage.

If that API shape would work for your use case, I’m happy to explore adding timers (or similar) as an option.

[Piratux]

@Piratux thanks for reporting an idea — could you tell me more about the use case you're trying to solve with web worker-based timers?

My use case is that I'm hosting a bot on website that communicates with game server on one browser tab. Then I can join game itself on another browser tab.

In some cases, when I send a packet from bot to game server, I require waiting in a loop until I receive back packet from server. As mentioned before, if I use browser's setTimeout functions (which your library defaults to) I run into tab throttling issues.

However, modern browsers can still throttle or even completely suspend background pages and their workers under certain conditions (e.g. long-hidden tabs, battery/memory pressure). So unfortunately the library cannot guarantee “non-throttled” timers just by switching to worker-based timeouts.

I was unaware of this. However, I've not run into such issues, and I don't really care if it doesn't work properly in 1% of edge cases.

If that API shape would work for your use case, I’m happy to explore adding timers (or similar) as an option.

Your proposed solution would work fine for me.