Assigned
Status Update
No update yet.
Comments
va...@google.com
Tested the issue on chrome version #127.0.6533.120 using Mac 14.6.1 as per
Steps to reproduce:
---------------------------
1.Launched chrome browser
2.Opened given link:http://44.216.23.255 and seen "open" and onopen event got fired
3.Turn off the wifi and observed "offline" event fired
Attaching screencast for reference
Reporter@ Could you please review the attached screencast and let us know if anything being missed here also please confirm if point:3 is the issue you are pointing to? please provide screencast of actual and expected behaviour for better understanding and further triaging the issue.
Note: Requesting you to copy the entire content of "chrome://version/?show-variations-cmd" details and please copy paste the info in .txt file format.
Thanks..!!
Steps to reproduce:
---------------------------
1.Launched chrome browser
2.Opened given link:
3.Turn off the wifi and observed "offline" event fired
Attaching screencast for reference
Reporter@ Could you please review the attached screencast and let us know if anything being missed here also please confirm if point:3 is the issue you are pointing to? please provide screencast of actual and expected behaviour for better understanding and further triaging the issue.
Note: Requesting you to copy the entire content of "chrome://version/?show-variations-cmd" details and please copy paste the info in .txt file format.
Thanks..!!
sp...@gmail.com
Your screencast confirms the incorrect behavior.
I have attached a screencast that shows the expected behavior.
Of course, chrome doesn't behave in the expected way anymore, so my screencast uses Safari to show the correct behavior. When working correctly, the browser emits "close" and "error" events when the websocket is no longer connected (such as when wifi is disconnected). You'll notice chrome does not do this in your screencast, but Safari does do it in my screencast. Chrome used to emit the "close" and "error" events but it doesn't anymore. I would like Chrome to be fixed so it behaves correctly. Chrome should follow the websocket spec and emit the "close" and "error" events when a websocket is closed.
I have attached a screencast that shows the expected behavior.
Of course, chrome doesn't behave in the expected way anymore, so my screencast uses Safari to show the correct behavior. When working correctly, the browser emits "close" and "error" events when the websocket is no longer connected (such as when wifi is disconnected). You'll notice chrome does not do this in your screencast, but Safari does do it in my screencast. Chrome used to emit the "close" and "error" events but it doesn't anymore. I would like Chrome to be fixed so it behaves correctly. Chrome should follow the websocket spec and emit the "close" and "error" events when a websocket is closed.
pe...@google.com
Thank you for providing more feedback. Adding the requester to the CC list.
va...@google.com
Tested the issue on chrome version #127.0.6533.120 using Mac 14.6.1, Win 11, Linux debian as per steps in
Reproducible on
=============
130.0.6682.2 - Canary
130.0.6669.2 - Dev
129.0.6668.12 - Beta
128.0.6613.85 - Stable
The same issue seems to be reproducible from M-117 older versions, hence considering it as Non-Regression and marking it as untriaged
Thanks..!!
Reproducible on
=============
130.0.6682.2 - Canary
130.0.6669.2 - Dev
129.0.6668.12 - Beta
128.0.6613.85 - Stable
The same issue seems to be reproducible from M-117 older versions, hence considering it as Non-Regression and marking it as untriaged
Thanks..!!
sp...@gmail.com
Thank you for testing this. This issue has been around since early 2023 so if you go back to Chrome #102 (roughly) you'll find the correct behavior and see that this a regression.
ni...@chromium.org
Hi Adam, could you take a look at this? Thank you!
bl...@gmx.de
Additionally switching Network to "throttled" or "offline" has no effect to the Websocket. I would expect the events to be fired here as well to debug offline behavior.
Description
Steps to reproduce the problem
The "close" and "error" events used to fire in chrome when the network connection was lost, and if you do the same steps in Safari or Firefox, you'll see the old chrome behavior (the "close" and "error" events do fire).
Yes, there is an offline event, but that's a different API -- all we're talking about here is that the websocket API is not following the websocket spec.
If the 44.216.23.255 site is not available, you can use any websocket connection with an error log.
Problem Description
Realtime web applications that are constantly sending and receiving data need to know when there is an interruption in the websocket connection. The websocket API provides two events for this, "close" and "error". Chrome has not been firing these two events since April 2023 (our best estimate based on what we've seen). These events are necessary to meet the websocket specification and for a good user experience in apps such as: stock trading, realtime analytics, realtime diagnostics, etc.
Additional Comments
This problem also started in Safari a few months before it happened in Chrome, but the issue has been resolved in Safari:https://bugs.webkit.org/show_bug.cgi?id=247943
Summary
The websocket API does not fire "close" and "error" events when the network connection is lost
Custom Questions
Which component does this fall under?
Not sure - I don't know
Does this work in other browsers?
Yes - This is just a Chrome problem
Additional Data
Category: API
Chrome Channel: Stable
Regression: Yes