8

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.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
SpaceBison
  • 3,704
  • 1
  • 30
  • 44
  • Do you ask for javascript frameworks or mobile-phone sdks? – Bergi May 24 '12 at 14:54
  • @Bergi Nothing specific, I've probably asked something that one person can't answer in that regard. It's more about finding out if there is a default behaviour of JavaScript (framework driven, or otherwise) – SpaceBison May 24 '12 at 14:59
  • It seems like you're conflating web standards with the behavior of the operating system. There's probably nothing in ECMAscript that says anything about whether the OS is allowed to stop the browser's process or not (does it even mention browsers?) --That is about the same as what is happening when you press that home key. There is no standard that governs this stuff. I could just as easily make a counter time out in a C program by hitting control z and stopping its process. A reliable counter should then be implemented on the server side, where the user can't stop it. – Thomas Dignan May 24 '12 at 15:04
  • @TomDignan Yes, very possibly true. (re: conflating x with y) - I realise there won't be any written, distinctive standard to govern this - I guess what I'm asking boils down to "Do mobile devices act in the same way" in regards to what I've described. There might not be anybody who exists who can actually answer this, though! – SpaceBison May 24 '12 at 15:11
  • @TomDignan: setTimout and co. are not even part of the ECMAScript standard. They are defined within the `Window` api. – Bergi May 24 '12 at 15:30

1 Answers1

11

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()).

Bergi
  • 630,263
  • 148
  • 957
  • 1,375