Open tomlarkworthy opened 2 years ago
This is the expected behavior: the Runtime has always used requestAnimationFrame
to schedule the next tick of computation, which is paused in background tabs.
Hmmm, I stand corrected on when this behaviour appeared. Would you want to change this behaviour? It's a bit of a usability issue for me. Seems like you could use setInterval when the tab is not foreground as a fix, but would you want to from a product perspective? (EDIT: I could probably do a fragile fix from userspace using access-runtime)
No, I don’t think this is something we’re considering changing: notebooks are primarily intended as user interfaces, not as applications or daemon processes. If you want the code to run in the background, you’re probably best opting out of the Runtime for scheduling computation, and instead manage the computation yourself (e.g., using setInterval and the invalidation promise to clearInterval).
The current behavior is good. (Even less resource use for background tabs would be better still. But I guess that’s up to browser policy.)
IMO, the current behavior is a great default, but it would be handy to be able to somehow flag that I really do want it all to keep running.
Note that Chrome will also throttle setTimeout / setInterval when a tab is running in the background: https://developer.chrome.com/blog/timer-throttling-in-chrome-88/
notebooks are primarily intended as user interfaces, not as applications or daemon processes
So I have a notebook that provides a button to deploy a notebook to s3: https://observablehq.com/@tomlarkworthy/notebook-deploy-to-s3
This downloads the tar, unpacks and does s3 putObject for each file. It can take a while. As progress indicator, I let each individual file in the tar pass through a "current file" cell. I feel this unrolling of loops into dataflow a nice pattern for long-running operations. However, if I switch tabs the deploy process stops :(
In my opinion this is neither a application nor a daemon process, and quite a good usecase of observable that is damaged by the runtime freezing when backgrounded.
Describe the bug This is a fairly old behaviour but I was unsure if it was normal JS or not, now I am sure it isn't
When you switch tabs, the runtime stops propagating changes. This can cause problems for long running process, networked applications etc. In my case it messes up livecoding (https://observablehq.com/@endpointservices/livecode).
I think this behavior was introduced with https://observablehq.com/@observablehq/visibility ?Anyway, I want a way to switch it off, IMHO, its an overreach into userspace and diminishes the usefulness of the environment, you can't make anything that works in the background (e.g. a chat application)To Reproduce visit https://observablehq.com/d/6f1bffd7be0752e5 and switch tabs, note the change in the console log.
Expected behavior I would expect normal Javascript behaviour that everything keeps running when switching tabs.
Desktop (please complete the following information):