backlog of "updates" is displayed in "fast forward" mode after getting back.

[rewolff]

The problem

I have a computer where sometimes we "switch users" from the "firefox looking at the 3D printers" to [other work]. When I switch back to the user having the firefox on octoprint... it starts "finishing the print" with time left and time printing going faster than realtime, but not at a speed that allows me to wait 5 seconds and then get on with my life.

During that time, stuff like "hitting reload" doesn't work either.

Now this is possibly a mostly firefox bug, but at least octoprint gui is doing something funny that causes this to happen.

Did the issue persist even in safe mode?

I cannot test this issue in safe mode (state why below)

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

It happens occasionally. Requires a 20h print to reproduce.

Version of OctoPrint

1.9.3 (also observed on earlier versions).

Operating system running OctoPrint

OctoPi

Printer model & used firmware incl. version

not relevant. Ender 3 S1 Plus.

Browser and version of browser, operating system running browser

Ubuntu 22.10, firefox 124.0.1 (64-bit)

Checklist of files to include below

• Systeminfo Bundle (always include!)
• Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

octoprint-systeminfo-20240413163747.zip
console.txt

Sorry I don't have screenshots setup on that computer.

[foosel]

This sounds like the updates from the backend sent via the websocket getting throttled into oblivion by the browser on backgrounding (that's something that browsers do these days, see also here), and then when you refocus the tab the UI gets all updates at once and has to apply them all. Which is a tad weird, I would expect the browser to still keep the websocket connection alive (as also written at the above link), so updates should still happen, but maybe after a certain point they aren't...

I have actually seen this once or twice myself, but always chalked it up to my system having been suspended in the meantime (which obviously would sever the connection), and it never did block the whole browser. It will take some time to find a way to reliably reproduce this in a timely manner (I cannot really go into debugging this when I have to first have to background a tab for hours on end), but I'll see what I can do in figuring out what even can be done on OctoPrint's side here.

[cp2004]

I have wanted to implement the "Page Lifecycle" API handling within OctoPrint for a while now. I suspect the process here is very similar to how 'sleeping tabs' features work, that the browser decides to freezes JavaScript (there's more to it, described on the link below), but doesn't disconnect the websocket. Reloading the page might be waiting for the existing JS callbacks to be processed before the page is removed & reloaded - closing the tab and then reopening it should be fine still.

I opened #4698 but never managed to dig in to it enough to start solving the issue. If my theory that the handling here is the same is correct, then I guess this is kind of a duplicate of that issue. I don't have time to dig into it, even though I'd love to... I can imagine a simple "test" plugin would be able to tell us if the API below is triggered in this case.

https://developer.chrome.com/docs/web-platform/page-lifecycle-api#state-frozen

https://wicg.github.io/page-lifecycle/spec.html

[rewolff]

One of the ways to solve it is that instead of handling: "Oh, time printed has updated to 1:22:33" and then repainting the screen, you just internally set the time-printed to that number, and tag "time printed" as "needs screen refresh. And only when there haven't been any updates for say 100ms do you start putting things on the screen. This on the assumption that you cannot "look ahead" to see if there are more updates pending. (no more queued data on the websocket.

The issue is that the repaint the screen takes say about 70ms, and the N updates at 70ms a piece takes a LONG time. If you can process the update in say 1ms then the "catch up with a day worth of updates" takes way less time so it becomes unnoticeable.

[cp2004]

That does start getting complex with the volumes of data that come through the OctoPrint websocket. There's a lot more than just a couple of fields that "need screen refresh", it's almost all of them - otherwise they would not be read. What you have described is essentially the principle behind UI libraries such as React, which hold a "virtual" model of the page and batch updates to render the page so that it is not constantly repainting.

I think, to handle this correctly the socket should be disconnected, so that the updates do not build up in a queue, and then when the page is unfrozen we reconnect and only have to process one websocket update.

Would have to work out a solution for the "assumption" that the UI will receive events to update it's state, which would be skipped. A prompt to reload would solve this, but it would of course be better to seamlessly update the UI if possible.

[rewolff]

Just noticed a way that might be easier to reproduce.... I just submitted a 29h job and after the slicer said "upload succeeded" I switched to my octoprint temperature view in my browser. Still operational.... and then afterwards... suddenly the temperature display started doing MANY more updates per second than what is normal. So even in that case, a buildup of update happens. In my case... It happened twice, as if took long while there were still updates queued.