Closed Bug 982743 Opened 9 years ago Closed 9 years ago
[B2G][Clock]Timer section's Resume button illuminates and doesn't resume timer countdown after specific steps on first interaction with App section only
As user accesses the timer section within the Clock App and both creates and begins the timer countdown but pauses the timer immediately, certain steps cause the Resume button not to work and the timer countdown not to continue. When the user taps the +1 Min button so that it is within a rectangular dotted box, and taps The Resume button, it highlights in blue and the previously paused timer after 1 minute increment remains at that timed section (i.e. 14:00.58 –14:00.58) until user taps the Resume button again. The Pause button returns to user view and the timer countdown resumes as expected. This appears to occur only during the first instance within the Timer section. Continuing this sequence thereafter doesn't seem to affect device performance. Repro Steps: 1) Updated Buri to BuildID: 20140312040203 2) Tap Clock App then Timer tab at bottom of device screen 3) Adjust hours & minutes sliders to desired selection and tap Start 4) Tap Pause as timer begins countdown then tap +1 Min once (so that it's within a dotted rectangular box) 5) Tap Resume once Actual: Resume button turns blue but timer doesn't resume Expected: Resume button changes to Pause and timer continues countdown Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140312040203 Gaia: 3005269d4dcabcc7d27eaf72bda44a969873af8c Gecko: 23005b395ae8 Version: 30.0a1 Base image: v1.2-device.cfg Repro frequency: 15/15 – 100% Link to failed test case: There is no word for word test case, this is the closest - https://moztrap.mozilla.org/manage/case/11314/ See attached: video clip = http://youtu.be/JiF0L6dai8M
This issue does not reproduce on the 1.3 Buri though the STR in Comment 0 cannot be completed on this build - specifically Step 4. Tapping the +1 Min button is not an option on the 1.3 Build. Attempts of other taps to reproduce behavior on 1.3 Buri was unsuccessful. Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140312004001 Gaia: df157ce3a3f841850a1cce8f057f8e7f547fb9f8 Gecko: c629684b0eae Version: 28.0 Base image: v1.2-device.cfg
This isn't a regression if the +1 min option didn't exist on 1.3.
Seems like this is a broken new feature to me. We either need to fix this or backout the feature.
blocking-b2g: --- → 1.4?
Clock is not in the descoped feature list, can we back out?
I'm seeing inconsistency in the behavior as described in the STR. At first, I wasn't able to reproduce. And then, I could reproduce consistently, not just the first time the camera was opened. I'm looking into this.
Assignee: nobody → rnicoletti
Status: NEW → UNCONFIRMED
Ever confirmed: false
When this problem reproduces, the clock is not receiving the "resume" event. That is, after tapping "+1 Min", and then tapping "Resume, Timer.Panel.prototype.onclick is not called. When "Resume" is tapped again, Timer.Panel.prototype.onclick is called.
I changed the "timer-plus" element to a button because as an anchor tag it was for some reason causing problems with click events.
Attachment #8391610 - Flags: review?(m)
blocking-b2g: 1.4? → backlog
Whiteboard: dogfood1.4 → dogfood1.4 [priority]
Disagree with the blocking decision here. I already clarified above that this breaks a basic use case with a new 1.4 feature. This needs to be turned off if it isn't resolved.
blocking-b2g: backlog → 1.4?
Comment on attachment 8391610 [details] [review] Pull request https://github.com/mozilla-b2g/gaia/pull/17215 Thanks, Russ! I manually verified that this fixed the problem and that the timer +1 functionality still works as expected. r=mcav.
Attachment #8391610 - Flags: review?(m) → review+
I have merged the patch into master. Candice, please let me know if the patch should be merged into 1.4. Thanks.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Russ Nicoletti [:russn] from comment #10) > I have merged the patch into master. Candice, please let me know if the > patch should be merged into 1.4. Thanks. Well, you need for approval first. But yes, this is worthwhile asking for approval - it's good cleanup work for a 1.4 feature. Can you ask for approval for 1.4? https://github.com/mozilla-b2g/gaia/commit/79f1ea0a236c11506b5e0adeaa8af119593df720
(In reply to Russ Nicoletti [:russn] from comment #10) > I have merged the patch into master. Candice, please let me know if the > patch should be merged into 1.4. Thanks. Great work Russ! Since it was not deemed as a blocker for 1.4. Let's leave on master and plan for 1.5. It barely missed the train here but it's not a show stopper. Thanks
(In reply to Candice Serran (:cserran) from comment #12) > (In reply to Russ Nicoletti [:russn] from comment #10) > > I have merged the patch into master. Candice, please let me know if the > > patch should be merged into 1.4. Thanks. > > Great work Russ! Since it was not deemed as a blocker for 1.4. Let's leave > on master and plan for 1.5. It barely missed the train here but it's not a > show stopper. Thanks I disagree with this. Issues that are considered good bugs to fix with low risk control are perfectly acceptable to take to the 1.4 branch right now, as we are taking patches for 1.4 that are safe for uplift that low risk & high value. This bug is a good example of a papercut worth uplifting.
I agree with Jason -- I think this is a great candidate for requesting approval-gaia-1.4+, but that flag isn't yet available on Bugzilla. I'm talking with peeps now asking why it's not there yet.
Comment on attachment 8391610 [details] [review] Pull request https://github.com/mozilla-b2g/gaia/pull/17215 [Approval Request Comment] This is a minor, low-risk fix. [Bug caused by] (feature/regressing bug #): Timer +1 Min feature. [User impact] if declined: Users may have to tap the "+1 Min" button twice to see any effect. [Testing completed]: Yes; patch confirmed to fix the problem. [Risk to taking this patch] (and alternatives if risky): Low risk. [String changes made]:None.
Attachment #8391610 - Flags: approval-gaia-v1.4?(fabrice)
FYI, link to merge revision in master: https://github.com/mozilla-b2g/gaia/commit/79f1ea0a236c11506b5e0adeaa8af119593df720
Comment on attachment 8391610 [details] [review] Pull request https://github.com/mozilla-b2g/gaia/pull/17215 approved by relman for gaia 1.4
Attachment #8391610 - Flags: approval-gaia-v1.4?(fabrice) → approval-gaia-v1.4+
[Environment] Gaia 53edbf08b0a750c31e8c6b2c20f2b1315b1412d1 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/9b482d6994fd BuildID 20140320160207 Version 30.0a2 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu Nov 14 10:58:33 CST 2013 [Result] Failed If you tap button quickly, the bug still can be reproduced.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That isn't the same bug - this bug doesn't deal with fast tapping, it deals with tapping at a normal speed when the timer is paused. Please open a followup.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
I agree with Jason that any issue with fast tapping is unrelated to this bug and should therefore be a separate bug.
keep monitor this issue
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.