dash-core-components dcc.Interval as background process

Issue discovered in community: https://community.plot.ly/t/dash-working-as-a-background-process/10412

It looks like dcc.Interval freezes when the app is not in the foreground. once the app is the in the foreground again, the dcc.Interval process "catches up". This behavior appears to change depending on the browser (with firefox there's less of a freeze when inactive.)

interval

It looks like this might be the browsers themselves trying to avoid hogging resources. I'm not sure if there's a way to override this behavior, but even if there is it might not be desirable.

If it's not desirable, I could imagine other tactics to deal with this. Perhaps a reload button that redraws the app and associated dcc.Interval component (I think that should clear the buildup of updates), or perhaps even another component that detects whether the app is active or inactive, which can then be used to turn off the dcc.Interval

May 24 '18 19:05 charleyferrari

More context: https://stackoverflow.com/questions/5927284/

May 27 '18 01:05 chriddyp

There are a few exceptions to the aggressive background tab throttling. One of these would be to use a websocket connection instead of http requests to establish the Dash connection as this is one of the automatically exempted cases.

https://developers.google.com/web/updates/2017/03/background_tabs

There are a number of automatic exemptions from this throttling: Applications playing audio are considered foreground and aren’t throttled. Applications with real-time connections (WebSockets and WebRTC), to avoid closing these connections by timeout. The run-timers-once-a-second rule is still applied in these cases.

Or not, depending on what run-timers-once-a-second rule means exactly. Or yes, as webworkers seem to be generally exempted from that rule.