982743 - [B2G][Clock]Timer section's Resume button illuminates and doesn't resume timer countdown after specific steps on first interaction with App section only

Status: VERIFIED FIXED

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

Description

[Montoya Clemmons (MClemmons)]

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

Comment 1

[Montoya Clemmons (MClemmons)]

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

Comment 2

[Jason Smith [:jsmith]]

This isn't a regression if the +1 min option didn't exist on 1.3.

Comment 3

[Jason Smith [:jsmith]]

Seems like this is a broken new feature to me. We either need to fix this or backout the feature.

Comment 4

[Preeti Raghunath(:Preeti)]

Clock is not in the descoped feature list, can we back out?

Comment 5

[Russ Nicoletti [:russn]]

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.

Comment 6

[Russ Nicoletti [:russn]]

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.

Comment 7

[Russ Nicoletti [:russn]]

Attachment: Pull request https://github.com/mozilla-b2g/gaia/pull/17215

I changed the "timer-plus" element to a button because as an anchor tag it was for some reason causing problems with click events.

Comment 8

[Jason Smith [:jsmith]]

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.

Comment 9

[Marcus Cavanaugh [:mcav]]

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.

Comment 10

[Russ Nicoletti [:russn]]

I have merged the patch into master. Candice, please let me know if the patch should be merged into 1.4. Thanks.

Comment 11

[Jason Smith [:jsmith]]

(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

Comment 12

[Candice Serran (:cserran)]

(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

Comment 13

[Jason Smith [:jsmith]]

(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.

Comment 14

[Marcus Cavanaugh [:mcav]]

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 15

[Marcus Cavanaugh [:mcav]]

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.

Comment 16

[Russ Nicoletti [:russn]]

FYI, link to merge revision in master:

https://github.com/mozilla-b2g/gaia/commit/79f1ea0a236c11506b5e0adeaa8af119593df720

Comment 17

[Preeti Raghunath(:Preeti)]

Comment on attachment 8391610 [details] [review]
Pull request https://github.com/mozilla-b2g/gaia/pull/17215

approved by relman for gaia 1.4

Comment 18

[Ryan VanderMeulen [:RyanVM]]

v1.4: 03c862e147c684ba1b569a9c2c07ae5bff4896f5

Comment 19

[Edward Chen[:edchen]]

[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.

Comment 20

[Jason Smith [:jsmith]]

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.

Comment 21

[Russ Nicoletti [:russn]]

I agree with Jason that any issue with fast tapping is unrelated to this bug and should therefore be a separate bug.

Comment 22

[Edward Chen[:edchen]]

keep monitor this issue