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!
Unable to reproduce on master. Flagging qawanted -- this would be a bad regression if we can reproduce.
Keywords: qawanted, regression
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.
Status: UNCONFIRMED → NEW
status-b2g-v1.2: --- → affected
status-b2g-v1.3: --- → affected
status-firefox29: --- → affected
Ever confirmed: true
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
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.
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.
Flags: needinfo?(doliver) → needinfo?(mike)
(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.
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.
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.
Whiteboard: [closeme 1/22/2014]
(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.
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
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.