You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 22, 2020. It is now read-only.
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).
The text was updated successfully, but these errors were encountered:
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:Presumably
window#hide
backgrounds aWindow
. Is that whyrequestAnimationFrame
s 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 thatrequestAnimationFrame
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 thatsetTimeout
andsetInterval
are not slowed down and thatrequestAnimationFrame
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 enablingrequestAnimationFrame
was never supported on hidden/backgroundedWindow
s?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 reconcilerFiber
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).The text was updated successfully, but these errors were encountered: