Closed Bug 982743 Opened 7 years ago Closed 7 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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog, b2g-v1.3 unaffected, b2g-v1.4 fixed, b2g-v2.0 fixed)

VERIFIED FIXED
1.4 S4 (28mar)
tracking-b2g backlog
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: mclemmons, Assigned: rnicoletti)

References

()

Details

(Whiteboard: dogfood1.4 [priority])

Attachments

(1 file)

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?
Whiteboard: dogfood1.4
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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]
Target Milestone: --- → 1.4 S4 (28mar)
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?
blocking-b2g: 1.4? → backlog
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: 7 years ago
Flags: needinfo?(cserran)
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
Flags: needinfo?(cserran)
(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)
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+
v1.4: 03c862e147c684ba1b569a9c2c07ae5bff4896f5
[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
Flags: needinfo?(rnicoletti)
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: 7 years ago7 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.
Flags: needinfo?(rnicoletti)
keep monitor this issue
Status: RESOLVED → VERIFIED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.