View Issue Details

IDProjectCategoryView StatusLast Update
0022919mantisbttime trackingpublic2017-09-03 18:41
Reporterethraza Assigned Todregad  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformChrome 58OSLinuxOS VersionUbuntu 16.04.2 L
Product Version2.4.1 
Target Version2.6.0Fixed in Version2.6.0 
Summary0022919: Time Tracking "auto count" is giving the wrong elapsed time
Description

After one month using the Time Tracking feature to track the time I spent working on each project I started to fell something was wrong with the time I was spending working. Today I finally noted down the time to verify the counter and find it was completely wrong.

What I found is that the elapsed time is always about 50% the time I really took working.

I don't know what math the counter is doing, but I noticed it is not really checking the time it started against the current time.

Steps To Reproduce

What I'm doing is starting the counter on the Mantis tab and go working in another tabs and programs, when I need to do something not related to this project, I go back to the Mantis tab and add the empty note with the elapsed time. Simple like that.

Additional Information

Example:
I started the counter at 10:15am.
At 11:15am I went back to Mantis tab to add the note.
Find out it was showing just about 30 minutes was passed (and counting).

TagsNo tags attached.

Activities

atrol

atrol

2017-05-23 15:39

developer   ~0056952

We use JavaScript setTimeout function for it.
I tried a bit and can confirm the issue, e.g. the timer takes longer on MacOs / Safari if the browser is not visible.

Depending on browsers the results are strange, especially if the browser tab is not active / visible.
https://stackoverflow.com/questions/22738493/settimeout-takes-longer-than-it-should
https://stackoverflow.com/questions/15871942/how-do-browsers-pause-change-javascript-when-tab-or-window-is-not-active

ethraza

ethraza

2017-05-24 12:09

reporter   ~0056955

As I was imagining. The setTimeout is probably just starting at 0 and adding each second to it.
I guess it would be better to start with a time and subtract it from current time.

Just an idea.
Maybe generating a new date every second is too much, so the current process of adding each second can be keept inside the minute for the seconds, and for the 0 seconds it can be recalculated subtracting current time from start time.

ethraza

ethraza

2017-08-09 13:39

reporter   ~0057414

Just sent a PR.
https://github.com/mantisbt/mantisbt/pull/1145

Related Changesets

MantisBT: master 85484ea4

2017-08-17 01:44

ethraza

Committer: dregad


Details Diff
Fix time tracking stopwatch lag

Prior to this, the stopwatch was lagging behind the real time and it was not
possible to manually edit the time field.

The lag was caused by the use of setTimeout to add to a counter each
second. Browsers put inactive tabs to sleep for a few seconds, causing
cumulative delays between each call to setTimeout.

I have changed setTimeout to setInterval to better express the intention
of calling a function in a loop and inside that function I have switched
from a simple add to a counter, to calculate the diff in seconds between
startTime and current time, using the moment.js library to help.

Fixes 0022919

Signed-off-by: Damien Regad <dregad@mantisbt.org>
Affected Issues
0022919
mod - js/common.js Diff File