HTML5: Game time / animations speed up after repeated tab switching (3.x, worked in 2.4.x)

[arungowda09]

Creator version: 3.8.3
Platform: Web / Browser (Chrome, Edge)
Regression: Yes (worked in 2.4.12)

Issue:
After repeatedly switching browser tabs (hide → show), the entire game gradually speeds up.
This affects:
Tweens
Click animations
UI feedback
Any animation using engine time
This is not limited to a specific tween or script. Even unrelated animations (e.g. clicking another piece) appear faster after several tab switches.

What I tried:
director.pause() / director.resume() on EVENT_HIDE / EVENT_SHOW
Restarting tweens
setTimeScale(1)
FPS locking
Refactoring animations
None of these prevent the speed-up.

Expected behavior:
Game timing should remain consistent after tab switching (same as 2.4.x behavior).

Actual behavior:
Engine time appears to accelerate after each tab switch.

Notes:
This did not happen in Cocos Creator 2.4.12 with the same logic.
Is this a known limitation or a regression in the Web scheduler / tween timing in 3.x?

[tvanle]

I dug through the 3.8.3 web pacer and Game to see whether the engine itself can end up running two main loops, which is what a cumulative speed-up usually means.

What the engine already does on tab switch. Game listens to systemInfo hide/show. On hide it emits EVENT_HIDE and then calls pauseByEngine(), which stops the pacer (cancelAnimationFrame on the pending handle). On show it emits EVENT_SHOW and calls resumeByEngine(), which only restarts the loop if the engine paused it itself. Pacer.start() and Pacer.stop() are both guarded by _isPlaying, so repeated hide/show can't stack loops through this path. So your director.pause()/resume() calls aren't needed, and they aren't what's fixing or breaking it. (The pacer code is the same in 3.8.4/3.8.5. 3.8.6 only adds USE_XR stripping, so upgrading won't change this.)

First, check whether it's more ticks or bigger ticks. Drop this into any component:

import { _decorator, Component, game } from 'cc';
const { ccclass } = _decorator;

@ccclass('TickProbe')
export class TickProbe extends Component {
    private _ticks = 0;
    onLoad() {
        const raf = () => {
            if (this._ticks > 1) console.warn('update ran', this._ticks, 'times in one browser frame');
            this._ticks = 0;
            requestAnimationFrame(raf);
        };
        requestAnimationFrame(raf);
    }
    update(dt: number) {
        this._ticks++;
        if (dt > 0.05) console.log('large dt', dt, 'game.deltaTime', game.deltaTime);
    }
}

• If you see update ran 2/3/4 times growing with each tab switch, something is starting an extra loop.
• If it's always 1 but things still speed up, the loop is fine and the extra speed comes from game code being registered again.

The usual culprits in the second case:

• game.on(Game.EVENT_SHOW, ...) or this.schedule(...) inside onEnable/start, or inside a SHOW handler, without a matching off/unschedule. Each switch adds one more callback, so everything driven by it runs N times faster after N switches.
• Tweens restarted in a SHOW handler without Tween.stopAllByTarget(target) first, so old and new tweens drive the same property.
• Any setInterval/setTimeout chain that gets re-armed on show.
• Code that calls game.resume() or director.startAnimation() by hand. That's the one path that can go around the engine's pause bookkeeping.

If the probe shows more than one update per frame in an empty project with only TickProbe in it, that's an engine bug. A minimal repro like that would be the thing to attach to an issue.