We noticed an issue with an application we are writing and I'm relatively sure that I've pinpointed the issue.
If JavaScript is being run in a window which is then hidden, at the point at which it is hidden requestAnimationFrame stops working. The API docs do not describe what the expected behaviour of this is or whether it is being backgrounded, however I suspect it is and understand that the default behaviour of most browsers is:
requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden <iframe>s in order to improve performance and battery life.
Presumably window#hide backgrounds a Window. Is that why requestAnimationFrames callback is never executed? Our application has been written so that it runs JavaScript in one window but renders into another, and currently the behaviour seems to mean that it will be impossible to use any libraries which use requestAnimationFrame (e.g. React 16). Ideally, we would like to be able to continue to do this, but ensure that the background is not throttled at all and that requestAnimationFrame still runs normally.
I notice that internally you are setting backgroundThrottling: false and we are not overriding this flag. I thought this was meant to ensure that setTimeout and setInterval are not slowed down and that requestAnimationFrame is still called.
I know you are loosely based on electron and hence share some of the same configuration. In fact, I think you have the same bug that Electron seems to have! I also found this related issue - maybe this implies that enabling requestAnimationFrame was never supported on hidden/backgrounded Windows?
What should the expected behaviour be? Is this broken? Will you fix it? Or will you consider this a feature request?
As you probably realise requestAnimationFrame is used frequently in modern libraries - for example, the new React reconciler Fiber makes frequent use of it (and I believe Angular uses it, too). If this can't be fixed, we will need to completely rethink the architecture that we were thinking of doing (for performance we were considering running the core JavaScript of our application in a hidden window while then rendering to multiple child windows).
We noticed an issue with an application we are writing and I'm relatively sure that I've pinpointed the issue.
If JavaScript is being run in a window which is then hidden, at the point at which it is hidden
requestAnimationFramestops working. The API docs do not describe what the expected behaviour of this is or whether it is being backgrounded, however I suspect it is and understand that the default behaviour of most browsers is:Presumably
window#hidebackgrounds aWindow. Is that whyrequestAnimationFrames callback is never executed? Our application has been written so that it runs JavaScript in one window but renders into another, and currently the behaviour seems to mean that it will be impossible to use any libraries which userequestAnimationFrame(e.g. React 16). Ideally, we would like to be able to continue to do this, but ensure that the background is not throttled at all and thatrequestAnimationFramestill runs normally.I notice that internally you are setting
backgroundThrottling: falseand we are not overriding this flag. I thought this was meant to ensure thatsetTimeoutandsetIntervalare not slowed down and thatrequestAnimationFrameis still called.I know you are loosely based on
electronand hence share some of the same configuration. In fact, I think you have the same bug that Electron seems to have! I also found this related issue - maybe this implies that enablingrequestAnimationFramewas never supported on hidden/backgroundedWindows?What should the expected behaviour be? Is this broken? Will you fix it? Or will you consider this a feature request?
As you probably realise
requestAnimationFrameis used frequently in modern libraries - for example, the new React reconcilerFibermakes frequent use of it (and I believe Angular uses it, too). If this can't be fixed, we will need to completely rethink the architecture that we were thinking of doing (for performance we were considering running the core JavaScript of our application in a hidden window while then rendering to multiple child windows).