Use of requestAnimationFrame means activities cannot take place in background

[thetorpedodog]

Description

We run a JupyterHub instance on top of Kubernetes. Launching a new JupyterLab notebook instance takes a minute or so, meaning users often switch to another tab and do something else while waiting for the notebook to load. However, other setup activities, like loading notebook files, starting kernels, and more does not actually take place until the user switches back. This may take another minute or two (during which they are likely to switch away again).

I traced this delay back to the fact that Lumino uses requestAnimationFrame to defer tasks. This does not run while the tab is in the background:

lumino/packages/polling/src/poll.ts

Lines 15 to 18 in 2d9b7aa

	const defer =
	typeof requestAnimationFrame === 'function'
	? requestAnimationFrame
	: setImmediate;

Reproduce

The full user experience won’t reproduce locally, but you can get a flavor of it and see the symptoms:

1. Launch a Jupyter Lab server (v3.4.5 will work), but don’t open the browser (jupyter lab --no-browser)
2. Open a new browser tab and open the developer tools, so you can capture network requests and activity.
3. Paste the URL that Jupyter Lab spit out at you. Hit enter and immediately switch to another tab (holding CTRL while hitting both ENTER and then PGUP (or PGDN) immediately after worked well for me).
4. Chill for a bit.
5. Return to the Jupyter Lab tab. Note that none of your notebooks etc. have loaded.

The long wait ↹’d in this screenshot is the time that I had another tab open.

Expected behavior

I would expect my session to restore itself and other things to load even if I had my tab open in the background.

Caveats and ideas

There probably is existing code that depends upon the existing “don‘t do work in the background” behavior. These are a few ideas for how to deal with that, listed from what seems (from my outsider’s perspective) from better to worse/harder:

• One solution might be to schedule deferred tasks immediately with setTimeout(...) if a requestAnimationFrame has not happened yet, and then once the first animation frame has been requested, use that instead.
• The existing code does say that the (nonstandard) setImmediate is an option if requestAnimationFrame does not exist. setTimeout (with no timeout) is the standard version of that and it could be used.
• Perform deferred tasks either on the next animation frame or on some longer timeout.
• Another thing might be to separate behavior that cares about whether the tab is visible/focused away from behavior that does not, and provide an interface to request either depending upon the caller’s need (though this would be more complex).

Context

• Operating System and version: Debian 11 (Bullseye)
• Browser and version: Chrome 106 (Windows)
• JupyterLab version: v3.4.5

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[krassowski]

I just want to say that as a user I hit this issue many times (often when leaving a binder tab loading in the background) and would like to thank you for investigating and providing a proposed solution.

I agree that setTimeout with 0 delay seems like a good idea here. There is a small chance that it could surface some race conditions which would not occur with the current requestAnimationFrame approach, so I would suggest we give it a try in the next lumino 2.0 alpha release.

[thetorpedodog]

The background issues might not be as bad as I would anticipate, since apparently they are throttled to 1 sec in most browsers.

[thetorpedodog]

As the automatic update above says, I created a draft review of the potential fix here: #395

If this is the right stage in the process for this (particularly given the scope of the change) I am happy to promote it from “draft” to “ready to review” but for now I just wanted to get it out there.

[thetorpedodog]

@fcollonval notes that this should probably also go back to 1.x, and the fix I have applies cleanly there.