Timers not working correctly after sleep/suspend

[flore77]

Hello!

I came across a behaviour where the timers do not work correctly in combination with computer sleep/suspend. Basically they are not respecting the set timeout and are firing instantly.

Steps to reproduce:

• leave a tab open
• put computer in sleep/suspend
• wake up
• any timer that is scheduled in the open tab will fire instantly

The issue resolves after a page refresh.

[chrisguttandin]

Hi @flore77,

thanks for reporting this. However I can't reproduce the problem locally. When I set up a timeout which is supposed to expire while the computer sleeps, the callback gets invoked once the computer wakes up again. If the timeout is supposed to expire later when the computer is up and running again it waits up until that point in time before invoking the callback.

On which browser/OS combination are you observing this?

[flore77]

Hei! Thanks for looking over this.

The behaviour I encountered is a little bit different in the sense that timeouts that are scheduled after the sleep are trigger immediately. Basically it doesn’t matter how long the computer is a sleep, it just matters that it was asleep and once woke up, all timeouts that are scheduled after this point are triggered instantly.

I reproduced it in Chrome on Linux (I will share the exact versions shortly).

[chrisguttandin]

Thanks @flore77, could you please log performance.now() at the time you schedule the timer and when it eventually invokes the callback? I'm curious how much time has elapsed according to the browser.

[flore77]

@chrisguttandin I had it log at the time I was debugging, if I remember correctly it fired as fast as it could, 1-2ms was what I observed in the logging.

The behaviour I observed was on:

Chrome:  115.0.5790.170 (Official Build) (64-bit)
OS: Ubuntu 20.04.6 LTS

[chrisguttandin]

Thanks for getting back. Chrome v115 is almost 2 years old by now. I built a simple demo to reproduce the problem but it works as expected on Chrome v134 on Ubuntu.

https://stackblitz.com/edit/typescript-eouqdppj?file=index.ts,index.html

Do you have a chance to check what it does when using Chrome v115?

[MasherJames]

@chrisguttandin I have also experienced this exact issue and I'm on.

Chrome: version 140.0.7339.213 (Official Build) (arm64)
OS: macOS Sonoma version 14.5

It's not really predictable when reproducing(happens sometimes and not all the times). Just as explained above, when I leave a tab open and my computer sleeps, coming back at it causes the setInterval function to fire erroneously.

[Ansile]

Encountering the same behaviour on

Chrome/122
OS: MacOS Tahoe 26.1

It does not seem to be consistent. Will try to check performance.now when next encountering this.

[Ansile]

I managed to catch it a few more times.

Using this function:

function testIntervalAccuracy() {
    console.debug('=== setInterval Accuracy Test ===');
    
    const interval = 1000; // 1 second
    let expectedTime = performance.now() + interval;
    let iteration = 0;
    const maxIterations = 10;
    
    const intervalId = setInterval(() => {
        iteration++;
        const actualTime = performance.now();
        const deviation = actualTime - expectedTime;
        
        console.debug(`Interval ${iteration}:`);
        console.debug(`  Expected: ${expectedTime.toFixed(2)}`);
        console.debug(`  Actual: ${actualTime.toFixed(2)}`);
        console.debug(`  Deviation: ${deviation.toFixed(2)}ms`);
        
        if (deviation < -500) { // More than 500ms early
            console.debug('🚨 INTERVAL FIRED TOO EARLY!');
        }
        
        expectedTime += interval;
        
        if (iteration >= maxIterations) {
            clearInterval(intervalId);
            console.debug('Interval test completed');
        }
    }, interval);
}

testIntervalAccuracy();

I got

VM425648:14 Interval 1:
VM425648:15   Expected: 1870911.60
VM425648:16   Actual: 1869919.10
VM425648:17   Deviation: -992.50ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 2:
VM425648:15   Expected: 1871911.60
VM425648:16   Actual: 1870000.60
VM425648:17   Deviation: -1911.00ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 3:
VM425648:15   Expected: 1872911.60
VM425648:16   Actual: 1870009.20
VM425648:17   Deviation: -2902.40ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 4:
VM425648:15   Expected: 1873911.60
VM425648:16   Actual: 1870020.90
VM425648:17   Deviation: -3890.70ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 5:
VM425648:15   Expected: 1874911.60
VM425648:16   Actual: 1870141.20
VM425648:17   Deviation: -4770.40ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 6:
VM425648:15   Expected: 1875911.60
VM425648:16   Actual: 1870159.80
VM425648:17   Deviation: -5751.80ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 7:
VM425648:15   Expected: 1876911.60
VM425648:16   Actual: 1870164.90
VM425648:17   Deviation: -6746.70ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 8:
VM425648:15   Expected: 1877911.60
VM425648:16   Actual: 1870170.40
VM425648:17   Deviation: -7741.20ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 9:
VM425648:15   Expected: 1878911.60
VM425648:16   Actual: 1870175.90
VM425648:17   Deviation: -8735.70ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:14 Interval 10:
VM425648:15   Expected: 1879911.60
VM425648:16   Actual: 1870180.70
VM425648:17   Deviation: -9730.90ms
VM425648:20 🚨 INTERVAL FIRED TOO EARLY!
VM425648:27 Interval test completed

@chrisguttandin here's the performance.now data you asked for.

I'm pretty sure the the fact that the delay is more than 0ms is due to other setInterval i have firing and hogging the main thread, not the actual worker-timer - it seems to be firing almost immediately.

[maxsmaleha]

Hi! I tried to use this lib in a my app and I faced to a similar error.
I develop some widget, that other teams integrate into some crm-like system. My widget is a javascript application, that is written in a typescript, and it builds into 1 js file via webpack. A crm-system loads this js-file, and initialize my widget from a global scope. It was fine on a dev\qa envs (because not a lot of people use it), but once it almost crush production. When crm-system need to reinitialize my widget, they do it from a first step, i.g. load script file, even if it was loaded before, and initialize my widget. In some cases it starts to make timer instant trigger. I added logs, and everything was clear on my side: timers setted up with a correct timeout. But it triggers instantly after creating. No matter what I use: a chain of setTimeout, or just setInterval, it triggers instantly. Only browser page reload helps in this case.

I tried to make a demo to reproduce this bug, but it was no successful. I read a code of this lib and its helpers. I think this problem related to performance.timeOrigin code in this lib, but I unable to proof it.

There is a issue with the same problem: #442