4 ms·
Re stopping timers: The timer id is afaik just a steadily increasing number starting at 1 which is returned by setTimeout() so you can iterate through them, e.g
by Jakob 9y ago
Re stopping timers: The timer id is afaik just a steadily increasing number starting at 1 which is returned by setTimeout() so you can iterate through them, e.g. to stop all:
for (let i=1; i++; i<=setTimeout('')) {
clearTimeout(i);
}
Though that’s an implementation detail which could change in the future since the spec seems to not enforce it.
- aiham 9y agoThat happens to be how common browsers have implemented it but the spec does not guarantee it: > Let handle be a user-agent-defined integer that is greater than zero that will identify the timeout to be set by this call in the list of active timers. https://dev.w3.org/html5/spec-preview/timers.html https://dev.w3.org/html5/spec-preview/timers.html Edit: Just noticed your edit.
- dspillett 9y agoIt might be safer to loop in reverse: for (let i=setTimeout(''); i--; i>=0) { clearTimeout(i); } That way if the optimiser decides not to optimise such that the termination condition doesn't call setTimeout() every iteration, you don't end up with an infinite loop because the result of setTimeout('') ends up incrementing in-step with the value of i. That advantage of browser support, assuming it was internal support and not tacked on in the dev-tools, would be that they could implement a toggle so the timers can be reactivated after you've finished checking what they were getting in the way of. [note: interval timers may need to be considered as well as timeout timers, unless they use the same ID counter with not type checking so either can be turned off by either clearTimeout() or clearInterval() - again that may be an implementation detail that varies between browsers]
- Jakob 8y agoGood catch on the reverse loop, you’re right.