User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111107 Ubuntu/10.04 (lucid) Firefox/3.6.24 Build ID: 20111107172717 Steps to reproduce: Set an alarm. And choose snooze option when it rings. Keep on selecting "snooze" continuously for 2-3 times. Make sure device can enter in suspend mode i.e no USB connected and keep screen time-out setting as low as possible. Actual results: Snooze works only for 1-2 times but after device goes in suspend state ,Alarm doesn't ring and crossed it snooze interval. It rings after we press power button. i.e when we resume device back manually. Expected results: Alarm should ring even if device is in suspend state.

Hi PoojaS, I cannot reproduce the issue with build version 20130423070204(b2g18). Snooze works normally in 6~7 times. Then I close the alarm in the 7th attention message. Could you please update your build version? Thank you.

HI Ian Liu, I can see this issue to every 2nd snooze . Are you sure device was in suspend state before you got alarm attention screen ? Also for me if alarm is set and set alarm time is already passed with device is in suspend state ,then as soon as i connect the USB it resumed back and started ringing. the latest gecko commit in my build is (released on 25-04-2013): 950b402b6188bb2f3ce3176e620ed5249719d720 Not sure exactly how to give you build version :( .Let me know if this build information is not sufficient for you.

(In reply to PoojaS from comment #2) > HI Ian Liu, > > I can see this issue to every 2nd snooze . > Are you sure device was in suspend state before you got alarm attention > screen ? > Yes, I check device was in suspend state after set an alarm with 5 mins later. > Also for me if alarm is set and set alarm time is already passed with device > is in suspend state ,then as soon as i connect the USB it resumed back and > started ringing. > I don't see the symptom. And I try to reproduce the issue with un-plug power line. > > the latest gecko commit in my build is (released on 25-04-2013): > 950b402b6188bb2f3ce3176e620ed5249719d720 > Not sure exactly how to give you build version :( .Let me know if this build > information is not sufficient for you. You could find out the build version via Settings App --> Device information --> More Information --> Build Identifier section.

Thanks Ian..build version is : 20130421193023

Seems a dupe of Bug 866366. The root cause is probably the CPU wake lock issue, because the alarm won't ring on time until you turn on the screen.

Issue still persist even with patch in Bug 866366. Even though results are not consistent.Some time alarm rings after along delay and some time its does not ring at all. Its easily reproducible after 2-3 iteration of snooze .

I think PoojaS' experimental result is very different from Ian's. :O Let's reopen this bug and ask for QA's support.

HI Gene, Please ignore comment 9 To confirm this unexpected alarm behavior at my end i have added few logs in gecko and gaia.Below is summary for that 1.I added alarm for 22:25 and received respective Gecko Fire system message at 22:25 (as expected). ============ 01-06 22:25:00.210 123 123 I Gecko : AlarmService: _onAlarmFired() 01-06 22:25:00.210 123 123 I Gecko : AlarmService: _removeAlarmFromDb() 01-06 22:25:00.210 123 123 I Gecko : AlarmService: _notifyAlarmObserver() 01-06 22:25:00.210 123 123 I Gecko : AlarmService: Fire system message: {"date":"1980-01-06T22:25:00.000Z","ignoreTimezone":true,"data":{"id":2,"type":"normal"},"pageURL":"app://clock.gaiamobile.org/index.html","manifestURL":"app://clock.gaiamobile.org/manifest.webapp","timezoneOffset":0,"id":7,"alarmFiredCb":null} ============== 2.Now i was expecting that i should receive Gaia :: mozSetMessageHandler at 22:25 so that it will handle the alarm and open the alarm page on UI. But from the logs we can see ,after i connect the USB then on 22:28 gaia received navigator.mozSetMessageHandler() call ============ 01-06 22:28:53.250 526 526 E GeckoConsole: Content JS LOG at app://clock.gaiamobile.org/gaia_build_defer_index.js:296 in gotMessage: inside mozSetMessageHandler : alarm message received =========== I have also collected logs without resuming device manually i.e without connecting USB. So here we again got gecko Fire system message at time but alarm message didn't reached upto gaia. Build version : 20130509142420 Both logs are attached : Suspend Resume http://prism/CR/462139 : cm task timeout http://prism/CR/469196 gaia app https://bugzilla.mozilla.org/show_bug.cgi?id=856524 --Gaia app https://bugzilla.mozilla.org/show_bug.cgi?id=865570 --Suspend resume http://www.slideshare.net/cjgiridhar/pycon11-python-threads-dive-into-gil-9315128 http://cros-bm-p1.qualcomm.com:8080/source/s?defs=clnt&project=ics_strawberry

I really apologize for creating confusion (dont know how to remove added attachment) added wrong description to below attachment attachement : 747967: Adb logcat.Alarm didnt worked and resumed device using USB meant for logs without USB connection .And alarm did not worked at all.Collected logs without USB connection.

> (dont know how to remove added attachment) Up at the top of the page, click "details" next to the relevant attachment, and then click "edit details". Now you can edit the attachment's description, or mark it as "obsolete", which is the closest thing to deleting it.

This issue is not reproducing on Unagi and Leo.Tested more than 10 times Unagi Build ID: 20130510070207 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/2aba3b5ac1c2 Gaia: fcaa90923894211c19b3544b5cb16eb0db5a6286 Leo Build ID: 20130507070204 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/884ad1bbe24e Gaia: 1bac83700810f27e00a937e34e7c865da02e0215 Unable to test on Ubuntu. Is it a device specific?

(In reply to pallavi from comment #14) > Unable to test on Ubuntu. Is it a device specific? Yes, it's device specific for now. The support for desktops is under way.

Cancel the needinfo which was an accident. Ian, QA (comment #14) and I still couldn't reproduce this bug. Ian, could you please confirm the Build ID things with PoojaS form the Gaia point of view? I'm wondering we're not really sync'ed with the same codes.

PoojaS, Could you please provide the device information which is running with build 20130509142420 ? According comment 10, I suspect it's a CPU wakeLock issue again. We have to make sure that your build version is including of bug 866366.

Reproduced on Keon with v1-train as of right now. I checked, Bug 866366 is in the gecko tree. I'll try to investigate.

Hi Ian Liu, Its on Akami ^2 and build version i used already have the patch addressed for CPU wake lock issue in Bug 866366. plz let me know the other device info you want me to share. platform version : 18.0 Software : Boot2Gecko 1.1.0.0-prerealese

In recent two days, I've tested the following two sets: - Unagi (Gecko b2g18 + Gaia v1-train) - Hamachi (Gecko v1.0.1 + Gaia v1.0.1) at least 10 times for each of them but they're still not reproducing. Hi Alexandre, how about your Keon? Does it work?

(In reply to Gene Lian [:gene] from comment #20) > In recent two days, I've tested the following two sets: > > - Unagi (Gecko b2g18 + Gaia v1-train) > - Hamachi (Gecko v1.0.1 + Gaia v1.0.1) > > at least 10 times for each of them but they're still not reproducing. > > Hi Alexandre, how about your Keon? Does it work? As far as I've tested monday, there was some issues on the Keon too. I've updated gaia yesterday, so I'll retry.

It seems like I'm reproducing it on Keon with gaia master at ec6e4178f3227f6adac6191855072a89b6bbc6a6 and gecko b2g18. One alarm that I set for 16:05 got triggered at 16:08.

Seems working on gaia v1-train at 0ddb515f15cbc6b74fc2742b7599d6ae74c6413f, an alarm configured for 16:36 fired at 16:36.

Reproduced also on gaia v1-train at 0ddb515f15cbc6b74fc2742b7599d6ae74c6413f, alarm configured for 16:50 fired at 16:55.

I don't remember having this issue at all on Keon with v1.0.1. Looking at git, I see that the only difference on apps/clock/js/onring.js is commit 87cc896b7a2016df090169dd1ba21bba1e879722 which relates to bug 848006. I'll try and see if reverting this helps.

With an alarm configured for 11:39: AlarmService fires at 11:39. system-messages-open-app message gets fired at 11:39, so b2g/chrome/content/shell.js calls shell.sendSystemMessage() on time. Next step is a "open-app" to be delivered to Gaia. All I can say is that open-app on gaia sides happened at 11:40. I'm currently investigating to ensure whether mozChromeEvent is send on time or not.

(In reply to Alexandre LISSY :gerard-majax from comment #26) > With an alarm configured for 11:39: > > AlarmService fires at 11:39. system-messages-open-app message gets fired at > 11:39, so b2g/chrome/content/shell.js calls shell.sendSystemMessage() on > time. Next step is a "open-app" to be delivered to Gaia. > > All I can say is that open-app on gaia sides happened at 11:40. I'm > currently investigating to ensure whether mozChromeEvent is send on time or > not. Alexandre, Nice catch. It's a CPU wake lock issue which is also discussed at Bug 866366. https://bugzilla.mozilla.org/show_bug.cgi?id=866366#c39.

(In reply to Ian Liu [:ianliu] from comment #27) > (In reply to Alexandre LISSY :gerard-majax from comment #26) > > With an alarm configured for 11:39: > > > > AlarmService fires at 11:39. system-messages-open-app message gets fired at > > 11:39, so b2g/chrome/content/shell.js calls shell.sendSystemMessage() on > > time. Next step is a "open-app" to be delivered to Gaia. > > > > All I can say is that open-app on gaia sides happened at 11:40. I'm > > currently investigating to ensure whether mozChromeEvent is send on time or > > not. > > Alexandre, > Nice catch. It's a CPU wake lock issue which is also discussed at Bug 866366. > https://bugzilla.mozilla.org/show_bug.cgi?id=866366#c39. Does it means that bug 865570 is still a dup of 866366 ? At least from my understanding of the comment you are linking, it seems it's the case and the current bug should be closed, right ?

This bug is still a duplicate of bug 866366.

I'd prefer letting it open to keep track of the testing scenario here, although the root cause seems the same. We can close this issue when we're sure the snoozing behaviour is also working well.

Hi Poojas, Could you please help verify this again since bug 866366 lands? We need more eyes on this kind of random issue. I believe it's working well now. A reminder: please do make sure your build includes the check-ins at bug 866366, comment #87. Thanks!

Resolve this with duplicate of bug 866366.

Hi Gene Lian, I'm from Pooja's team. Fix for bug 866366 works properly. We don't see this issue anymore.

(In reply to vasanth from comment #33) > Hi Gene Lian, > > I'm from Pooja's team. Fix for bug 866366 works properly. We don't see this > issue anymore. Thanks vasanth and Pooja. Thanks God!