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

RESOLVED DUPLICATE of bug 866366

Status

Firefox OS
Gaia::Clock
P2
major
RESOLVED DUPLICATE of bug 866366
5 years ago
5 years ago

People

(Reporter: Pooja, Assigned: Gene Lian (I already quit Mozilla))

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+)

Details

Attachments

(4 attachments)

(Reporter)

Description

5 years ago
Created attachment 741680 [details]
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.
(Reporter)

Updated

5 years ago
Blocks: 856773
Severity: normal → major
blocking-b2g: --- → leo?
OS: All → Gonk (Firefox OS)
Priority: -- → P2
Hardware: All → ARM
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.
(Reporter)

Comment 2

5 years ago
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.
(Reporter)

Comment 4

5 years ago
Thanks Ian..build version is : 20130421193023
(Assignee)

Comment 5

5 years ago
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.

Updated

5 years ago
Status: UNCONFIRMED → RESOLVED
blocking-b2g: leo? → leo+
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 866366
(Reporter)

Comment 7

5 years ago
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 .
(Assignee)

Comment 8

5 years ago
I think PoojaS' experimental result is very different from Ian's. :O Let's reopen this bug and ask for QA's support.
Status: RESOLVED → REOPENED
Ever confirmed: true
Keywords: qawanted
Resolution: DUPLICATE → ---
(Reporter)

Comment 9

5 years ago
Created attachment 747964 [details]
adb logcat.Device resumed using USB
(Reporter)

Comment 10

5 years ago
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
(Reporter)

Comment 11

5 years ago
Created attachment 747967 [details]
Adb logcat.Alarm didnt worked and resumed device using USB
(Reporter)

Comment 12

5 years ago
Created attachment 747971 [details]
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.
> (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

5 years ago
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?

Updated

5 years ago
Keywords: qawanted
(Assignee)

Comment 15

5 years ago
(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.
Flags: needinfo?(poojas)
(Assignee)

Comment 16

5 years ago
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.
Flags: needinfo?(poojas)
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.
Flags: needinfo?(poojas)
Reproduced on Keon with v1-train as of right now. I checked, Bug 866366 is in the gecko tree. I'll try to investigate.
(Reporter)

Comment 19

5 years ago
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
Flags: needinfo?(poojas)
(Assignee)

Comment 20

5 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 866366
(Assignee)

Comment 30

5 years ago
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

5 years ago
Summary: Snooze doesn't work once device goes in suspend state. → [Alarm] Snooze doesn't work once device goes in suspend state.
(Assignee)

Updated

5 years ago
Assignee: nobody → gene.lian
(Assignee)

Comment 31

5 years ago
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!
(Assignee)

Comment 32

5 years ago
Resolve this with duplicate of bug 866366.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 866366

Comment 33

5 years ago
Hi Gene Lian,

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

Comment 34

5 years ago
(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!
You need to log in before you can comment on or make changes to this bug.