Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rapid multiple executions after tabs get focus again on mobile device #5

Open
dnmd opened this issue Nov 26, 2018 · 2 comments
Open

Comments

@dnmd
Copy link

dnmd commented Nov 26, 2018

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 dnmd changed the title rapid multiple executions after resum rapid multiple executions after tabs get focus again on mobile device Nov 26, 2018
@dnmd
Copy link
Author

dnmd commented Nov 26, 2018

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();
}

@aduth
Copy link
Owner

aduth commented Dec 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants