Description
Is your feature request related to a problem? Please describe.
I've created a SignalR application and it's been working well for a while now, but as the newest versions of chrome have been rolling out I've noticed that when I'm not actively using the web app, the app loses connection to the SignalR server because it's taking too long to handshake. I've done some digging into this and I believe this is due to the javascript throttling that occurs in a tab/window running in the background and/or being frozen with the new grouped tab freezing logic.
Describe the solution you'd like
Would like to see at minimum some doc around this at the links below in the SignalR area so developers are aware of it, and a suggested withAutomaticReconnect and ServerTimeout settings to alleviate the issue if possible (I'll be messing with this myself to see if I can get something that doesn't end up dropping the connection via the various properties).
https://docs.microsoft.com/en-us/aspnet/core/signalr/javascript-client?view=aspnetcore-5.0
Ideally SignalR should "just handle it" but I'm not sure of a programmatic workaround at the moment for this.
Additional context
Chrome Release notes on these two features:
https://chromeenterprise.google/policies/?policy=IntensiveWakeUpThrottlingEnabled
From chrome 91 release notes:
Chrome allows users to organize tabs into collapsible groups, helping them stay productive. For some users, Chrome 91 pauses those tabs when the user collapses them, to reduce CPU and power consumption. Chrome does not pause tabs if they are playing audio, holding a web lock, holding an IndexedDB lock, connected to a USB device, capturing video or audio, being mirrored, or capturing a window or display.
While not currently an issue with firefox or edge, if this is the beginning of some sort of new energy-smart paradigm in browser behavior it could have much wider reaching implications for SignalR and polling across the web in general. Might be worthwhile to get in front of it.