865570 - [Alarm] Snooze doesn't work once device goes in suspend state.

Status: RESOLVED DUPLICATE of bug 866366

(Firefox OS Graveyard :: Gaia::Clock, defect, P2)

Description

[Pooja]

Attachment: alarm_snooze_notWorking.zip

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.

Comment 1

[[e-mail], [e-mail]]

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.

Comment 2

[Pooja]

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.

Comment 3

[[e-mail], [e-mail]]

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

Comment 4

[Pooja]

Thanks Ian..build version is : 20130421193023

Comment 5

[Gene Lian (I already quit Mozilla)]

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.

Comment 7

[Pooja]

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 .

Comment 8

[Gene Lian (I already quit Mozilla)]

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

Comment 9

[Pooja]

Attachment: adb logcat.Device resumed using USB

Comment 10

[Pooja]

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

Comment 11

[Pooja]

Attachment: Adb logcat.Alarm didnt worked and resumed device using USB

Comment 12

[Pooja]

Attachment: logs of alarm when it get expired and used USB to ring it up

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.

Comment 13

[Justin Lebar (not reading bugmail)]

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

Comment 14

[pallavi]

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?

Comment 15

[Gene Lian (I already quit Mozilla)]

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

Comment 16

[Gene Lian (I already quit Mozilla)]

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.

Comment 17

[[e-mail], [e-mail]]

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.

Comment 18

[:gerard-majax]

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

Comment 19

[Pooja]

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

Comment 20

[Gene Lian (I already quit Mozilla)]

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?

Comment 21

[:gerard-majax]

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

Comment 22

[:gerard-majax]

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.

Comment 23

[:gerard-majax]

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

Comment 24

[:gerard-majax]

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

Comment 25

[:gerard-majax]

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.

Comment 26

[:gerard-majax]

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.

Comment 27

[[e-mail], [e-mail]]

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

Comment 28

[:gerard-majax]

(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 ?

Comment 29

[:gerard-majax]

This bug is still a duplicate of bug 866366.

Comment 30

[Gene Lian (I already quit Mozilla)]

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.

Comment 31

[Gene Lian (I already quit Mozilla)]

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!

Comment 32

[Gene Lian (I already quit Mozilla)]

Resolve this with duplicate of bug 866366.

Comment 33

[vasanth]

Hi Gene Lian,

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

Comment 34

[Gene Lian (I already quit Mozilla)]

(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!