[GitHub issue by timdream on 2012-09-18T10:07:56Z, https://github.com/mozilla-b2g/gaia/issues/4857] /blame me, I should have find out earlier. The problem lies at Line 107 of system/js/wifi.js. At the moment, upon the conditions are met,`setTimeout` was executed and should turn off wifi after 60 sec. But that `setTimeout` timer is never executed, presumably because the CPU is in fact asleep. So, questions: 1. If CPU is let to sleep, what's the point to turn off wifi? 2. Does it make sense to set a 60 sec CPU wake lock just for turning off wifi if we should turn it off? CCing @kanru @vingtetun @michaelwu Related issue: [Bug 784733] Otoro device drains overnight when left untethered with wifi enabled https://bugzilla.mozilla.org/show_bug.cgi?id=784733

[GitHub comment by kanru on 2012-09-20T10:47:40Z] 1. If the CPU is unable to sleep for some reason, then the timer will go off. 2. No. However you should reset the timer after CPU wakeup.

[GitHub comment by autonome on 2012-09-24T15:51:46Z] Blocking for battery drain. If the CPU is asleep it doesn't make sense to have much else running.

[GitHub comment by timdream on 2012-09-25T04:31:45Z] Let's use Alarm API for that 60 sec timeout ...

[GitHub comment by timdream on 2012-09-26T11:08:54Z] I cannot make System app to successfully access Alarms API, which is very bad. Gonna try to keep the CPU awake for 60 sec instead.

[GitHub comment by timdream on 2012-09-27T11:21:13Z] Hum ... wake lock seems useless even it does set `mozPower.cpuSleepAllowed` to false.

Gene, I need your help on this one. https://github.com/timdream/gaia/compare/c8983e2f...timdream:a2b73b8 I've written a patch that I believe it should work, however upon "wiki timer set" message, I didn't receive any callback on line 75. What can possible go wrong? Is there a DEBUG param I can set in System Message script that I can see what's going on internally?

I can support to take a look on that. I'll come back with some testing results. Please stay tuned. :)

I've already narrow down the root cause (please refer to bug 797803) but need to discuss more with Fabrice to work out an optimal solution to solving it.

Problem with mozSetMessageHandler is being workarounded with idea described in bug 797803 comment 6

(In reply to Gene Lian [:gene] from comment #8) > I've already narrow down the root cause (please refer to bug 797803) but > need to discuss more with Fabrice to work out an optimal solution to solving > it. Btw, bug 797809 has already been r+'ed and is going to be checked in sooner or later in a couple of days. That would help you in the future if you'd still prefer receiving system messages within the System App. ;)