Possible Windows Chrome 151+ change causing SignalR/WebSocket tabs repeatedly disconnect after client keepalive stops

[Reagan Yuan]

Hello Chromium team,

We are investigating a Chrome-specific increase in WebSocket disconnect and reconnect activity in a collaboration web application.

The issue appears primarily on Google Chrome for Windows beginning with Chrome 151. Microsoft Edge on the same Chromium major versions does not show the same increase. Has there been any change around Chrome 151+?

Environment
- Windows 10/11
- Google Chrome 151 and later
- ASP.NET Core SignalR JavaScript client 10.0.0
- WebSocket transport
- Server client-inactivity timeout: 50 seconds
- Client SignalR keepalive interval: 20 seconds
- Server SignalR keepalive interval: 15 seconds

The SignalR client contains the fix from:
https://github.com/dotnet/aspnetcore/pull/63195

Observed behavior
1. The WebSocket initially operates normally.
2. The client stops sending SignalR messages and keepalive pings.
3. The server closes the connection after approximately 50 seconds with:
   "Client hasn't sent a message/ping within the configured ClientTimeoutInterval."
4. Chrome periodically gives the page enough execution time to reconnect.
5. The new WebSocket again lasts approximately 50 to 52 seconds.
6. The cycle repeats.

I could not reproduce this behavior on the Browser using various modes of power saver and laptop not plugged in. I am on a Windows machine.

Chrome versus Edge comparison

For Windows sessions using the same Chromium major versions, we observe these approximate failure rates:

Chromium 151:
- Chrome: 7.9%
- Edge: 1.3%

Chromium 152:
- Chrome: 10.6%
- Edge: 1.2%

Chromium 153:
- Chrome: 14.2%
- Edge: 1.7%

Chromium 154:
- Chrome: 18.9%
- Edge: 1.5%

Chromium 155:
- Chrome: 16.9%
- Edge: 1.6%

Chrome 150 was close to the Edge baseline. The increase begins around Chrome 151.

The comparison uses the same application, Windows platform, server environment, and message-volume eligibility criteria. 

Chrome on macOS is also much closer to Edge than Chrome on Windows. The strongest affected cohort is specifically Windows Chrome.


The timing looks similar to Chrome's Infinite Tabs Freezing behavior.

Relevant changes:

Infinite Tabs Freezing, part 1:
https://chromium-review.googlesource.com/c/chromium/src/+/6533477

Periodic unfreezing, part 2:
https://chromium-review.googlesource.com/c/chromium/src/+/6532710

Avoid inactive Infinite Tabs unfreeze timers:
https://chromium-review.googlesource.com/c/chromium/src/+/8183269

User-configurable tab freezing backend:
https://chromium-review.googlesource.com/c/chromium/src/+/8285541

Could above produce the observed behavior:
- Chrome unfreezes the page briefly.
- SignalR reconnects.
- Chrome freezes the page again.
- JavaScript timers and network callbacks stop running.
- The server reaches its 50-second client-inactivity timeout.
- The next periodic Chrome unfreeze occurs near 60 seconds.

The Chrome freezing documentation states that freezing suspends timers, promise resolvers, and network event handlers. A plain WebSocket does not appear in the documented exemption list.

The user-configurable freezing change also states that background tab freezing previously ran entirely under internal feature flags. This raises the possibility of a Chrome Finch/Variations rollout that would not affect Edge and would not necessarily appear in public release notes.

Questions

1. Were any Infinite Tabs Freezing, memory-pressure freezing, or related Finch studies expanded around Chrome 151?
2. Is a hidden page with an active plain WebSocket intentionally eligible for Infinite Tabs Freezing?
3. Does the 60-second interval and 5-second periodic unfreeze behavior apply to stable Chrome populations?
4. Is there a supported mechanism for a real-time WebSocket application to opt out of freezing?
5. Should adding a site to "Always keep these sites active" prevent both discarding and freezing?
7. Could a Chrome-specific enterprise policy or Finch configuration explain why Edge on the same Chromium major is unaffected?


We would appreciate guidance on whether this matches a known Chrome freezing experiment or regression.

Thank you!