makes it a little difficult to write tests that make use of the media progress timer.
Sinon does not currently support faking window.performance - sinonjs/sinon#803. So relying on Date().getTime() would be preferable from a testing perspective, but because now is a private function that is initialised when the module is loaded, it is not possible to add a stub or monkey patch at this stage.
I'm using the timer in the Mopidy-Musicbox-Webclient project, and have encountered a situation where the timer appears to 'die' unexpectedly. Steps to reproduce:
timer is started and appears to function normally.
move browser window to the background for several minutes (at least one or two track changes) so that the window / tab does not have focus and is not updated.
switch back to the browser window / tab. The timer no longer updates an appears to be 'stuck'.
Debugging the Javascript, it appears as if ProgressTimer.prototype._update is no longer being called, so the callback is never executed either. I've encountered this issue with the latest versions of Safari and Firefox.
Could it be that window.requestAnimationFrame stops being invoked by the browser at some point or am I misunderstanding how the timer works? I haven't tried the disableRequestAnimationFrame fallback yet as I would ideally like to make use of the lower CPU-load approach offered by the standard options.
The default does not at all work well with requestAnimationFrame, likely we want to consider just disabling the update rate for the requestAnimationFrame code path and then renaming it to fallbackUpdateRate or something like that.
I noticed this on latest Chrome (41.0.2272.101).
When the tab is inactive for some time, it stops working as probably setTimeout is not fired.
I didn't find any solution yet.
You can test it on http://mopster.cowbell-labs.com where this library is integrated.