[Sora][Clock][Timer] After unlocking screen, it doesn't stay original interface when create timer.

VERIFIED FIXED in 1.4 S1 (14feb)

Status

Firefox OS
Gaia::Clock
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: sync-1, Assigned: mcav)

Tracking

unspecified
1.4 S1 (14feb)

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

(Whiteboard: [p=3])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
build ID: 20140105004001
 
 DEFECT DESCRIPTION:
  After unlocking screen, it doesn't stay original interface when create timer.
 
  REPRODUCING PROCEDURES:
  1. Enter "Clock"->"Timer";
  2. Edit time of the "Timer";
  3. Waiting for time out or lock screen;
  4. Unlock screen.
 
  EXPECTED BEHAVIOUR:
  Should stay original interface.
 
  CONTACT:021-61460666-7035.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Could you try to verify again with Mozilla Build ID: 20140120102858 ? it works fine for me on build 20140120102858
Flags: needinfo?(sync-1)

Comment 2

4 years ago
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #1)
> Could you try to verify again with Mozilla Build ID: 20140120102858 ? it
> works fine for me on build 20140120102858

The time you selected will not be kept and slide to the initial value after unlocking screen.
Hi Dylan -

This one is really minor...ni you to just let you know our partner report it
Flags: needinfo?(doliver)
Reproduced -- nominating to get this one in front of the team but agreed with Vance that this is a minor issue.
blocking-b2g: --- → 1.4?
Flags: needinfo?(sync-1)
Flags: needinfo?(doliver)

Comment 5

4 years ago
Maybe keeping  the previous value of index and top in reset function on spinner.js can resolve this issue.
(Reporter)

Comment 6

4 years ago
Cannot reproduce on Mozilla build ID:20140118004001
(Reporter)

Comment 7

4 years ago
sorry,it still can reproduce on Mozilla build ID:20140118004001.
(Assignee)

Comment 8

4 years ago
Created attachment 8369623 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/15924
Assignee: nobody → m
Status: NEW → ASSIGNED
Attachment #8369623 - Flags: review?(mike)
blocking-b2g: 1.4? → backlog
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
Comment on attachment 8369623 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/15924

Hi Marcus: I think we'll need a slightly more complicated approach to correctly fix this bug--see the pull request on GitHub for details.
Attachment #8369623 - Flags: review?(mike)
(Assignee)

Comment 10

4 years ago
Mike, you're right that it would need to be more complex to implement
the current behavior (resetting on pause/resume). It strikes me as
strange that we reset on pause/resume; I'm going to confirm with Adam
to see if that's actually the behavior we want here.

Adam, right now, when you cancel/end a timer, the time selector
reverts to "0:00" no matter what you had selected previously. I'd like
to argue that it should _not_ reset; that if I just set a 10-minute
timer, when I hit "Cancel" or the timer expires, the time picker
should still show ten minutes.

Rationale:

- As a user, I set a timer for 10 minutes baking cookies. I'm baking
  several batches. After the first batch is done, I want to set
  another timer for exactly the same time. The timer should remain
  configured for "10 minutes" so that I don't have to reselect the
  time from the picker every time.

- As a user, I set a timer for one hour to take a nap. I start the
  timer to take a nap, but realize that I forgot to do something
  first. I hit "Cancel", do my thing, and then want to come back to
  take the nap. It would be annoying if I had to reset the timer to
  the time I had just set.

- iOS (and I think Android) keeps the time you've selected even if you
  cancel the timer. (see the Baking Cookies example)

- By resetting it to zero every time (the current behavior), I as the
  user have to do extra work every time I use the timer, even if I
  always use the timer for one duration.

Thoughts?
Flags: needinfo?(arogers)
Actually, I can't remember if there was an explicit specification for this behavior. Mostly I wanted to avoid unintentional changes to the interface. I think it's the right call to get Adam's input here.

This may also have an effect on the yet-to-be-merged integration tests in bug 907177, so we should keep an eye on the order these patches land and update accordingly.

Comment 12

4 years ago
There are more usage scenarios that would prefer the timer to not reset - it's common to use a similar timer over and over as you describe, Marcus. 

I would concur that the preferred behavior is to set the timer back to the previously set time.  Ie; show 00:10:00, not 00:00:00, after the end of a  10 minute countdown. 

Going to ni UX here for their input.
Flags: needinfo?(arogers) → needinfo?(jhuang)
Target Milestone: 1.3 C3/1.4 S3(31jan) → 1.4 S1 (14feb)
(Assignee)

Updated

4 years ago
Whiteboard: [p=3]

Comment 13

4 years ago
Agree with Adam & Marcus. It's reasonable to keep the time instead of reset it after a countdown.
Flags: needinfo?(jhuang)
(Assignee)

Comment 14

4 years ago
Comment on attachment 8369623 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/15924

Mike, given Adam's feedback, I think the patch already does what we'd like to have it do. Could you verify/review in that context?
Attachment #8369623 - Flags: review?(mike)

Comment 15

4 years ago
this should be fixed in v1.3, thanks.
blocking-b2g: backlog → 1.3?
UX,

Please chime in on right display of time.
Flags: needinfo?(firefoxos-ux-bugzilla)
We have the UX input in comment #13 and a patch awaiting review. 

For triage: this is a very minor issue in my view -- it doesn't affect a running timer. Only a user that locks the screen between the actions of setting the timer value and starting the timer, who would then need to reset the timer value. We are fixing this in 1.4 but I don't think we should block 1.3.
Flags: needinfo?(firefoxos-ux-bugzilla)
Discussed via Vance - there's agreement now this isn't a blocker.
blocking-b2g: 1.3? → backlog
Comment on attachment 8369623 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/15924

Wow, it looks like you've already incorporated my feedback! Once the TravisCI build completes, this should be ready for `master` :)
Attachment #8369623 - Flags: review?(mike) → review+
(Assignee)

Comment 20

4 years ago
Landed:

https://github.com/mozilla-b2g/gaia/commit/b0e4c9c5557192bccf14ccc07621efe7bac5f050
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
[Verified info]
Gaia      6e71ab4da1b08586ea0c758edb7aa199ee34cd2f
Gecko     https://hg.mozilla.org/mozilla-central/rev/bb030d47c946
BuildID   20140219160202
Version   30.0a1

[Testing result]
PASS
Keep previously set time and no other side effects. I mark it to "VERIFIED"
Status: RESOLVED → VERIFIED
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.