998209 - [Clock] didn't wake me up today

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

Attachment: 2014-04-18-07-51-36.png

Context: I upgrade my dogfood phone from v1.3 to v1.4 2 days ago. Not sure the migration story is related to this issue though.

I have an alarm set up to ring every week day at 7.30am.

The day I upgraded the phone, the alarm was first triggered at a wrong time (around 5:53pm IIRC). The next day, the alarm correctly rang at 7.30am.

Today, it didn't ring, but when I woke up the device, I saw the full-scren alarm screen without any text, and the buttons didn't react. I pressed home and I still saw the alarm banner at the top, still without any text. I could press it to show the full-screen alarm screen again, but with the same behavior.

Unfortunately, I couldn't get the logcat because I dropped the phone and the battery came off :(

In case it's useful: the phone had USB plugged in to a power outlet.

QAWanted to try to reproduce on Buri and find better diagnostics.

Comment 1

[Duane Dixon [:ddixon]]

Unable to reproduce issue on Buri 1.4 build.  

Repro Steps used:
1. Plug phone into power outlet to charge battery. 
2. Launch Clock App 
3. Set an alarm to trigger 3 to 60 minutes later. 
4. Allow alarm to trigger. 

Attempted these steps 25 times and could not reproduce issue. 

According to attached screenshot, battery was fully charged.  I kept my device fully charged during repro attempts as well.

Comment 2

[Jason Smith [:jsmith]]

Can we also try testing this by creating an alarm on a Leo device on 1.3, upgrading to 1.4, and then checking to see if the alarm fires?

Comment 3

[Julien Wajsberg [:julienw]]

The problem is that it worked once, and then it didn't work once. The next time it's supposed to ring is next monday...

Comment 4

[Julien Wajsberg [:julienw]]

worked today; yesterday I was not next to the phone, I saw the alarm screen 10 minutes later but didn't hear if it ringed. Definitely I didn't see attachment 8408792 [details].

Note that I disabled/enabled the alarm since then so maybe this "fixed" the issue...

Comment 5

[Marcus Cavanaugh [:mcav]]

My current working theory on this is that perhaps the mozAlarms get lost during the upgrade from 1.3 to 1.4. (I haven't tested that, but it would explain this bug.)

Bug 996306 tracks adding verification on Clock startup that would ensure every alarm's mozAlarm is properly set. I believe E-mail does this for sync, as if I recall :jrburke had some trouble with mozAlarms disappearing under certain conditions. That might help with similar issues in the future.

That said, if we can reproduce this bug, it'd be best to fix it properly (unless the system is actually losing the mozAlarm.)

Comment 6

[Preeti Raghunath(:Preeti)]

Sounds like a data loss issue from data migration. Blocking 1.4 for the same.

Comment 7

[Julien Wajsberg [:julienw]]

Problem with the dataloss theory is that it worked fine the first day... I think I'll try to update another 1.3 phone with an alarm set and see if I can reproduce.

Comment 8

[Marcus Cavanaugh [:mcav]]

Today, I did the following:

1. Flashed a 1.3 image on a Keon.
2. Set an alarm.
3. Used the system update to update the phone to 1.4 (build 32a9e3db 2014-04-23 14:53:30).
4. The alarm fired correctly.

Julien, is that upgrade process (via system update) how you upgraded the phone?

Comment 9

[Dylan Oliver [:doliver]]

Moving back to 1.4? -- we are unable to reproduce and without clear STR we can't block on this issue.

Comment 10

[Julien Wajsberg [:julienw]]

As I said, it worked once for me too, and then it didn't work once. So I don't really expect this to be a migration issue, but there might be a race condition somewhere.

I upgraded using geeksphone's builds but this is doing the same than you, I guess.

Comment 11

[Dylan Oliver [:doliver]]

Please re-nominate if reliable STR can be found.

Comment 12

[u505123]

I've experienced the same issue since upgrading to the geeksphone 1.4 image for the peak as soon as it came out (around 2014-04-07 if I remember correctly). I did a complete reflash with the most current geeksphone image on 2014-04-26 though, with userdata deleted. The problem persists.

For me, it only happens once after doing an OTA update. If I reboot a second time after the system update reboot the alarm rings as expected.

Comment 13

[Julien Wajsberg [:julienw]]

Thanks, that's very useful !

Renominating then.

Comment 14

[Jason Smith [:jsmith]]

Going to see if we can reproduce the STR in comment 12 for the QA Wanted request.

Comment 15

[Dylan Oliver [:doliver]]

I tried on master (triggered an OTA update via Settings|Check for updates) and was unable to reproduce. Alarms that had been created on the previous version worked as expected after the OTA restart.

Comment 16

[Jason Smith [:jsmith]]

James - Can you get someone to look into the QA Wanted request here?

Going to move to backlog until we get consistent STR to reproduce this.

Comment 17

[J Zimbrick]

I did not reproduce this after following Comment 12's steps to reproduce with a Buri device.

I flashed a Buri to 04/26's 1.4 build (which seems to be Comment 12's starting point), then did an OTA update to today's 1.4 build.

The first alarm that I had set did go off as expected after the update, and two other alarms after that went off as well without issue.

Environmental Variables:
Device: Buri
BuildID: 20140506000202
Gaia: b1242f33981024de59b8b4c26bacff8b876211b1
Gecko: fe4080728c60
Version: 30.0
Base Image: V1.2-device.cfg

Comment 18

[Jason Smith [:jsmith]]

Closing as wfm since we can't reproduce.

Comment 19

[u505123]

Rather peculiar, since when I did the OTA on 2014-05-06, it happened again to me. This time though, before setting the alarm, I had to hard-reset the device by taking out the battery because of an  overheating problem.
Well, waiting for a reliable STR then.

Comment 20

[Julien Wajsberg [:julienw]]

Saw the exact same screen again, exact same behavior, except I _think_ the alarm worked but I'm not sure as the phone was elsewhere.

What I think happened: the alarm worked, but I didn't stop it before several hours after the time.

Comment 21

[Julien Wajsberg [:julienw]]

Still a v1.4 build from last month on Peak.

Comment 22

[Julien Wajsberg [:julienw]]

I got the issue today, but not the exact same issue I was describing in comment 0.
I'm still using v2.0 on Flams-JB.

However, I reproduce with latest master nightly on Flame-kk, and here is a reproducible STR:

1. Set an alarm to "current time + 2 min"
2. Go to settings, set the date to "date + 1day"
=> The alarm should ring, press "Stop"
3. lock the phone, wait 2 minutes
=> The alarm should ring again, but doesn't

Note that I took care that the Clock app is not killed while being in background. I haven't tried if the Clock is killed. However in the usual case the Clock stays launched as background app.

This STR looks like an edge case, but truth is that it happens in real life. Step 2 happens in real life when we reboot the Flame, the Flame loses the date/time and the time is set at the correct time thanks to the network. Step 2 happens in real life when we cross timezone.

And in the end, this could explain lots of other bugs related to the time when the Clock is ringing.

Blocking now that I have a reproducible STR.

Comment 23

[Julien Wajsberg [:julienw]]

Additional information: I got the "alarm rings at reboot" issue (so step 2 here) yesterday during the day, and the alarm didn't ring for me this morning.

Comment 24

[Julien Wajsberg [:julienw]]

Hey Marcus, does this additional information help you?

Comment 25

[bhavana bajaj [:bajaj]]

I am adding qawanted to confirm this is reproducible on pvt user builds and we can block it form there.

Comment 26

[Cody Roesch [:croesch]]

Julien,
    Before I proceed on this bug I need to clarify something here. 

(In reply to Julien Wajsberg [:julienw] from comment #22)
 
> 1. Set an alarm to "current time + 2 min"
> 2. Go to settings, set the date to "date + 1day"
> => The alarm should ring, press "Stop"
> 3. lock the phone, wait 2 minutes
> => The alarm should ring again, but doesn't


In step 2, you say that the user needs to tap "STOP" on the alarm, then later the expected result for step 3 is that the alarm SHOULD ring again.

I'm confused because this sounds like snooze behavior. Can you clarify?

Thanks,
QA

Comment 27

[Julien Wajsberg [:julienw]]

So, the STR is a synthethized way to reproduce the issue in the real life.

What happens in real life is:
* instead of step 2, the phone's time is completely f***ed up, and at one point goes back to the right time. When that happens, the planned alarm ringed, and the user stops it accordingly.
* step 3 is what happens at the next cycle, like the next morning.

So you read correctly: we press "stop" to stop the first time it rings due to the clock change (because the alarm's planned time for "yesterday" is between the previous datetime and the new datetime). But I still expect the phone to ring at the right time that day.

Hope this is making my STR and the expected behavior clearer.

Comment 28

[Cody Roesch [:croesch]]

Based on the STR of comment 22 here are the results for the Flame device.

Tested with Shallow Flash on 319mb using Engineering builds

This bug DOES repro on Flame kk build: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK

Actual Result: The alarm does not ring a second time as expected.

Repro Rate: 6/6

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141112125016
Gaia: 65d593cdd9d88648045a30a63fc329b7bb5d340b
Gecko: 66cdb18f36da
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141112232645
Gaia: 569a299ca446f714cd98d5881cc058fd6f6e257b
Gecko: d188e92aa5a6
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141112171043
Gaia: ab83632c92f9fc571b11d8468b6901cc4ed905c0
Gecko: e21bf45e6c44
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 29

[Dylan Oliver [:doliver]]

Not blocking 2.1 on this but we will prioritize this for work in 2.2 and will pursue uplift to 2.1 if the branch is still active when we have a solution.

Comment 30

[BMO Automation]

Firefox OS is not being worked on