Closed
Bug 831453
Opened 12 years ago
Closed 12 years ago
[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
Categories
(Firefox OS Graveyard :: Gaia::Clock, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dholbert, Assigned: iliu)
Details
(Keywords: b2g-testdriver, polish, unagi, Whiteboard: interaction, UX-P2, TEF_REQ)
Attachments
(1 file)
STR:
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.
Reporter | ||
Comment 1•12 years ago
|
||
Build ID: 20130114070200
Comment 2•12 years ago
|
||
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).
Assignee | ||
Comment 3•12 years ago
|
||
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.
Josh,
Could you give some suggestion for the issue?
It's a polished issue.
Assignee: nobody → iliu
Flags: needinfo?(jcarpenter)
Reporter | ||
Comment 4•12 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
Comment 5•12 years ago
|
||
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)
Updated•12 years ago
|
Whiteboard: interaction, UX-P2, TEF_REQ
Assignee | ||
Comment 6•12 years ago
|
||
Pointer to Github pull-request
Assignee | ||
Comment 7•12 years ago
|
||
Comment on attachment 708473 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7889
Tim,
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)
Updated•12 years ago
|
Attachment #708473 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 8•12 years ago
|
||
Thanks for Tim's reviewing effort.
https://github.com/mozilla-b2g/gaia/pull/7889
Since the pr is merged, we can close the issue now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•