correctingInterval icon indicating copy to clipboard operation
correctingInterval copied to clipboard

rapid multiple executions after tabs get focus again on mobile device

Open dnmd opened this issue 6 years ago • 2 comments

Hi,

Thanks for this nice plugin! I did notice a small issue. The execution of setCorrectingInterval stops when a tab no longer has the focus on mobile devices. However when it receives focus again, say after 60 seconds, it catches up, with now(). This leads to a very strange effect. Within a couple of ticks, it tries to compensate for the gap of 60 seconds. Say you use this plugin for a clock, within those few ticks the clock is in sync again, but it looks like the clock is fast forwarding really quick. Comparing the behavior to setInterval, it just stops, and starts where it left of.

So as a suggestion;

  • mimic the setInterval, and continue setCorrectingInterval where it left of;
  • don't execute all the "intermediate" or "missed" intervals, but "reset" and start over again;

dnmd avatar Nov 26 '18 13:11 dnmd

The issue lies within planned - now() on line line 52, if that evaluates to a negative value, one could set planned = now(), so right after line 51, one could insert:

if(planned - now() < 0) {
  planned = now();
}

dnmd avatar Nov 26 '18 13:11 dnmd

Hey @dnmd, thanks for reporting this, and apologies for my lack of response thus far. It's been some time since I've maintained the code for this project, so I'll need to set aside some time to ingest the problem. As you describe it though, it certainly doesn't seem to be doing the correct thing in making repeated calls for the gap of time which was lost.

One thought which occurs to me by your recommendation is that if the catch-up is meant to occur effectively now (via the setTimeout( tick, 0 ) which would occur as a result of your code change), it makes me think that it might not need to be scheduled at all, and the callback could be invoked directly.

aduth avatar Dec 06 '18 13:12 aduth