Are there any standards for mobile device web browsers in terms of thread sleeping? [closed]

Question

Given the following jsFiddle, which is a simple incrementing counter

http://jsfiddle.net/C93ms/6/

....if I visit the url above using a mobile device (smartphone or tablet for the sake of argument), the counter starts incrementing as you'd expect provided there is JavaScript support, then it appears that if I press the "Home" button, or click the power button once to turn off the screen (but keep the phone powered on) then the script will stop running and the counter stops incrementing. This I expect to happen and I appreciate the reasons why as reserving battery life is hugely important on a mobile device, so it makes sense that the UI thread sleeps, or similar. Once you revisit the browser, the counter continues incrementing. In the real world, websites that determine timeout period using JavaScript would not timeout despite the inactivity period, I am assuming.

I am also assuming that this will vary by device, by firmware, by software even - what I'm trying to ascertain here is whether there's a standard approach or default behaviour built into mobile development frameworks for this and any form of consistency in how the devices behave.

I'm not totally sure I've asked a good question here, but I've struggled to find 100% relevant information from SO, or I don't quite know what the question is I need to ask when searching.

Answer 1

No JavaScript framework can stop the execution or change the behaviour of the underlying JS engine. They will not be able to influence setTimeout.

Yet, the behaviour is standardisized in the current HTML5 draft on the WindowTimers interface (which does not mean it was implemented like that). There you will find the note:

This API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected.

and, even more explicit:

9) Optionally, wait a further user-agent defined length of time.

Note: This is intended to allow user agents to pad timeouts as needed to optimise the power usage of the device. For example, some processors have a low-power mode where the granularity of timers is reduced; on such platforms, user agents can slow timers down to fit this schedule instead of requiring the processor to use the more accurate mode with its associated higher power usage.

You can see such behaviour also on desktop browsers, which implement a minimum timeout of 4ms (read explanation on MDN). So, it is legitimate for every device/software/firmware to stop such execution if they only think it would be necessary.

You might also want to have a look at the WindowAnimationTiming draft.

And if you do use setInterval/setTimeout in animations/clocks/etc, always measure the really elapsed time with Date objects (e.g. via Date.now()).