All users were logged out of Bugzilla on October 13th, 2018

[Clock] If I change an alarm time and then hit "back" (canceling the change) and then return to alarm, the dials spin from my canceled time to correct time



6 years ago
6 years ago


(Reporter: dholbert, Assigned: iliu)


({b2g-testdriver, polish, unagi})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: interaction, UX-P2, TEF_REQ)


(1 attachment)



6 years ago
 1. Create an alarm for 1:00 AM

 2. Tap that alarm (at the bottom of Clock app) to go into "Edit alarm" mode

 3. Change any or all of the dials to its absolute extreme other end.
    So, e.g. change it to read "12:59 PM"

 4. Hit "Back" in the upper-left corner. (Do NOT hit "Done".)
    --> This cancels your alarm modification.

 5. Tap the alarm (at the bottom of the Clock app) to go into "Edit alarm" mode again.

ACTUAL RESULTS: Time-picker starts out at my canceled time from step 3 (12:59 PM), and the dials quickly spin to end up at the correct time (1:00 AM).

EXPECTED RESULTS: Time-picker should already show 1:00 AM when I enter "Edit alarm" mode. There's no reason for it to have saved my canceled time.

Comment 1

6 years ago
Build ID: 20130114070200
I cannot reproduce this bug with the latest Gecko/Gaia builds. The time picker doesn't spin from the cancelled time as described at comment #0. However, I can feel it indeed spins a bit when re-entering the time picker, but it seems a normal UI behaviour.

CC'ing Rudy who is involved in the time picker things (I guess).
Keywords: qawanted
For the current behavior, I let the picker has an animation to the specific time. I personally think it will make the app more lively. Let's listen to UX's suggestion.

Could you give some suggestion for the issue?
It's a polished issue.
Assignee: nobody → iliu
Flags: needinfo?(jcarpenter)

Comment 4

6 years ago
From my perspective as a user, it felt odd to me that the time-picker left its dials at the time I'd tentatively picked but then canceled.

In my mind, it seems like canceling the alarm should "reset the dials" right away (even if I don't see it happen), because canceling restores the alarm to its original value.  Right now, it ends up not "resetting the dials" until the next time I look at them, which seems delayed.  Feels weird to me, but I may not be a typical user.
Keywords: polish
Good catch, Daniel. As per your reasoning, I agree that the Edit screen for each Alarm should display the time for that alarm immediately, without any sort of animated transition from another time.
Flags: needinfo?(jcarpenter)


6 years ago
Keywords: qawanted
Whiteboard: interaction, UX-P2, TEF_REQ
Created attachment 708473 [details]
Pointer to Github pull request:

Pointer to Github pull-request
Comment on attachment 708473 [details]
Pointer to Github pull request:


Could you please help to review my pr for the following change?

1. Remove class animation-on when the picker init.
2. Remove class animation-on when received transitionend event.
Attachment #708473 - Flags: review?(timdream)
Attachment #708473 - Flags: review?(timdream) → review+
Thanks for Tim's reviewing effort.
Since the pr is merged, we can close the issue now.
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.