Improvement for session closing/creation?

on the path for live updates (#3876) I implemented a method to track on the server side which clients are currently present called "sessions" for being able to broadcast updates to them.

People seem to consider it sufficient for now, but should be improved in the future. This issue is about continuing the discussion and finding a better way.

status quo

(when #3876 got merged)

Sessions are closed and recreated on a visibilitychange event, so when a tab gets closed, but also when moved into the background.

code: https://github.com/nextcloud/deck/pull/3876/files#diff-b664969071203fe9658373becc8ab4a07102326d7c234976125959fa83d73fadR107-R128

comments so far

@marcelklehr https://github.com/nextcloud/deck/pull/3876#discussion_r1031461098

closing the session when the tab is not active might be a bit confusing, even if it's technically a cool feature. Google Docs also doesn't do this afaik.

@nimishavijay https://github.com/nextcloud/deck/pull/3876#issuecomment-1339924671

I would say closing the session immediately after the tab is unfocused would be confusing. If there was a timeout of say, 15 mins or something that would make more sense :)

@juliushaertl https://github.com/nextcloud/deck/pull/3876#issuecomment-1367930524

I'd generally agree that the session close after the tab is in the background should rather be deferred for some time. This may also help to avoid additional load for creating and removing the extra sessions. That can also be a follow up of course ;)

my current opinion

after reading into some documents about how to track if a page got closed or also exiting the current page to a different nextcloud page, it seems that that the only way to reliable do that, is via the visibilitychange event.

• https://www.igvita.com/2015/11/20/dont-lose-user-and-app-state-use-page-visibility/
• https://web.dev/bfcache/

sure, visibilitychange is triggered quite often, even when a user is just switching the tab for a second, but there is no way to tell the browser to (reliably) defer a request to the backend, because the tab might get suspended at any time while being in the background.

we could still notify the backend about the visibilitychange event on the client when it occurs, but propagate it only when the session didn't came back for x seconds, but this would require, that we could trigger something deferred, but we are quite limited by php's architecture here - and I'm not sure what the actual gain would be (no real perfomance impact). It would definitely add complexity.

so I currently don't see a better way, but I'm happy for any proposal! :)

Start with the visibilitychange handling in the code diff linked from PR #3876, focusing on where sessions are closed and recreated. Review the documented discussion and determine an agreed lifecycle or deferred-close approach; done would require a defined behavior and its implementation, but the issue does not identify a specific file or accepted solution.