951108 - The Clock.app Timer suspends on app change

Status: RESOLVED WORKSFORME

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

Description

[Adrian Custer]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131213004002

Steps to reproduce:

When a Timer is started, and the user switches to another app, the Timer suspends rather than continuing. This is actually dangerous.

1. Start at the homescreen with no apps running
2. Launch the clock app
3. Switch to Timer tab
4. Set the Timer for one minute, push 'Start'
=> the countdown starts
5. Press the 'home' button
6. Launch the Settings app
7. Wait ten to twenty seconds or longer
8. Press the 'home' button
9. Re-open the Clock.app
=> the timer restarts from the time the Clock.app was last opened (i.e. 50+ seconds) *not* from the elapsed clock time since the timer was launched.


Actual results:

The Clock.app Timer suspends its countdown.


Expected results:

The Timer should keep going no matter what; it is a timer!

Comment 1

[Dylan Oliver [:doliver]]

Unable to reproduce on master. Flagging qawanted -- this would be a bad regression if we can reproduce.

Comment 2

[J Zimbrick]

This issue DOES reproduce exactly as stated in Comment 0 with the steps provided on a Buri device running the latest Mozilla 1.2, 1.3, and 1.4 builds. 1.1 builds do not appear to have a timer functionality.

1.2 Environmental Vairables:
BuildIDcd: 20140113004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: e672faf1e6a1
Version: 26.0
Base Image: V1.2-device.cfg

1.3 Environmental Variables:
BuildID: 20140113004002
Gaia: b3fc4f712562ee92b0ed0bd17abc61be9a36a8da
Gecko: 5bb1837de7c0
Version: 28.0a2
Base Image: V1.2-device.cfg

1.4 Environmental Variables:
BuildID: 20140113040202
Gaia: fd3b9a97cb3c41cfa56be387b46a51db136b4422
Gecko: 12d3ba62a599
Version: 29.0a1
Base Image: V1.2-device.cfg

At this point, I'm not sure if the issue is a regression or if it somehow was just never caught.
I'll look further in to some older 1.2 builds to see if the timer behaved this way when it was first introduced.

Comment 3

[J Zimbrick]

This is occurring in the first build I have that has a working Timer feature, so not a regression. 
I would consider this a pretty serious issue as the user would expect a timer to work in the background.

Environmental Variables:
Device: Buri v1.2 Mozilla RIL
BuildID: 20130917040201
Gaia: 1518b76c07c4d70fc41113ed2e424a74b2bcef27
Gecko: 1d27c4c9871f
Version: 26.0a1
Base Image: V1.2-device.cfg

Comment 4

[Jason Smith [:jsmith]]

This is pretty disappointing feature bug for the timer - the fact that this feature only works in foreground means that the user would have the keep the clock the whole time in the foreground to be notified that the timer is finished. They however, can't switch over to do something else, as the timer will suspend at this point.

Dylan - Can we get someone to look into this? Clock features probably won't block the release, but this seems pretty important to get fixed.

Comment 5

[Dylan Oliver [:doliver]]

Mike, do you have any thoughts here? Is this maybe specific to lower memory devices like Buri? I am unable to reproduce on Geeksphone Peak.

Comment 6

[Rick Waldron [:rwaldron]]

(In reply to Jason Smith [:jsmith] from comment #4)
> This is pretty disappointing feature bug for the timer - the fact that this
> feature only works in foreground means that the user would have the keep the
> clock the whole time in the foreground to be notified that the timer is
> finished. They however, can't switch over to do something else, as the timer
> will suspend at this point.

Have you actually tested and reproduced the issue? If yes, what device?

> 
> Dylan - Can we get someone to look into this? Clock features probably won't
> block the release, but this seems pretty important to get fixed.

I cannot reproduce this on an Inari—in fact, the Timer survived through `make install-gaia APP=clock` and re-opening the app (as I would expect it to). Let me know if a video record of the correct behaviour is needed.

Comment 7

[Mike Pennisi [:jugglinmike]]

I am unable to reproduce at Gaia revision fd3b9a97cb3c41cfa56be387b46a51db136b4422 on an Inari device. I do not have access to a Buri device.

I am not sure how memory capacity could trigger this behavior, but it's as good a guess as any as to why Rick, Dylan, and I are unable to reproduce. I may still have access to a Unagi; if this truly is a resource-related issue, this bug may be reproducible on that device.

I will leave the "needsinfo?" flag until I can confirm its availability and test there.

Comment 8

[Jason Smith [:jsmith]]

I can't reproduce this myself on a 1/12/2014 1.4 Buri build. However, I have noticed that there isn't any vibration firing when the timer hits zero while the clock in the background. I'm also seeing the old timer UI rendering initially before loading the creating a timer UI.

I'll check if there's bugs open for the two issues I mentioned & will file them if they aren't filed.

Comment 9

[Dylan Oliver [:doliver]]

(In reply to Jason Smith [:jsmith] from comment #8)
> However, I have
> noticed that there isn't any vibration firing when the timer hits zero while
> the clock in the background. 

That one is bug 958731.

Comment 10

[Rick Waldron [:rwaldron]]

Video note: you'll have to pardon one of my dogs growling at the other in the beginning of the video.

https://dl.dropboxusercontent.com/u/3531958/951108.mp4

Comment 11

[J Zimbrick]

Not sure if my Buri was in a bad state on the 13th or what, but I am also unable to reproduce this issue today on the latest 1.4 build. I also tried on the build from the 13th and had no issues.

The timer seems to count down as it should when it is in the background.

1.4 Environmental Variables :
Device: Buri v1.4 Mozilla RIL
BuildID: 20140115041401
Gaia: 255a56ac67e5b28f1fc78307969cc83391c9652f
Gecko: 81bced59e8b3
Version: 29.0a1
Base Image: V1.2-device.cfg

Going to go ahead and resolve this as works for me.