Opened 11 years ago

Last modified 9 years ago

#3439 new defect

Resume state

Reported by: humitos Owned by: RafaelOrtiz
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: StopWatch Version: Unspecified
Severity: Unspecified Keywords: AU
Cc: godiard, manuq, humitos Distribution/OS: Unspecified
Bug Status: New

Description

What's the idea of "Resume state" in StopWatch activity?

I noticed that the behavior is not always the same, and it's quite strange.

Step to reproduce it:

  1. Start a clean StopWatch activity
  2. You'll see all the clocks in "0,00"
  3. Start some clocks
  4. Add some marks to those clocks
  5. Stop the activity (remember the times)
  6. Resume the activity
    • All the mark will be there, and all the clocks will start running again but they don't resume the last state, instead of this they continued while you had the activity closed
  7. Stop again the activity
  8. Resume the activity
    • Again, you will see all the marks there, but now the clocks will be stopped and in 0,00 again.

So, two different behaviors with the same action.

Even more, if you start a new clock this time (the second time that you resumed the activity) it will be started when you open it again but if you close and open it again it will be stopped. So, the second time that you resume the activity the clocks are stopped.

Change History (2)

comment:1 Changed 10 years ago by quozl

  • Bug Status changed from Unconfirmed to New

Reproduced.

In my opinion, the clocks should continue to run while the activity is stopped, because this is how it was designed and discussed early on ... but the stopping of the clocks caused by the second stop and resume (steps 7 and 8) is a code defect. It does not occur if the clock that is running is stopped and started (step 6.5).

comment:2 Changed 9 years ago by nirajnakrani

  • Keywords AU added
Note: See TracTickets for help on using tickets.