Bug 278313 – WebSocket close event is not fired when close() is called.

• Status: RESOLVED
• Resolution: MOVED
• Component: WebKit Misc.

[Andrew Hodel]

Steps to reproduce the problem

1. Connect a new WebSocket();
2. Disgrace the network connection to ensure packets are delayed and dropped causing TCP resends (RST flagged packets). This is possible with iptables, pf, or by using your computer with a radio link and a poor radio signal. (WiFi, LTE, etc).
3. Call the close() function on the WebSocket object you created in step 1. As the WebSocket close() function was called within the code of the WebSocket client, the close event should fire immediately. It does not.

Problem Description

As the WebSocket close() function was called within the code of the WebSocket client, the close event should fire immediately. It does not.



If believe that a WebSocket close (opcode 8) message must be delivered for the close event to happen without a timeout triggering it:

You can kill the server and see that the close event on the client fires immediately without an opcode 8 message being sent. Either that or this must be a bug.
It is most reasonable that the WebSocket close() function makes the close event fire immediately because:

It makes reconnecting faster when you are sure there is a disconnection based on a keep-alive (ping, etc) mechanism.
Keep in mind that this only happens when there is a poor network connection.

[Alexey Proskuryakov]

We are tracking multiple issues that result in this behavior. There were two fixes in iOS 17.6.1. One was in WebKit, and one in an underlying system framework. But the issue doesn't appear to be fully resolved, so there is more to fix.

Which OS version are you observing this with?

[Andrew Hodel]

@Alexey Proskuryakov please link the issues using a hyperlink.

You have described the same routine as implementing a work-around to this problem/issue in JavaScript and it must not be the solution or fix.

[Alexey Proskuryakov]

I add the WebKit issue to See Also; others are Apple internal. My question still stands, which OS version are you observing this with?

[Andrew Hodel]

@ Alexey Proskuryakov

That's already specified in the bug's fields.

[Alexey Proskuryakov]

Please try to refrain from unwarranted snark.

The bug field says "iOS 17", and I'm asking you about the precise version, as some fixes went into iOS 17.6.1.

[Andrew Hodel]

@Alexey Proskuryakov

At this time, with this product the fact is that there is no reason to not have the latest updates by the Operating System if you are on Earth.  I think that is why the fields were not constructed correctly, alongside there not being an standard protocol or URL structure to import the data from the browser manufacturers.

I understand the problem of alignment of thought, regarding that this may not be true as latency of communication increases and believe that the field should have more specific version information.  I don't think your comment adequately explained that.

I am using the latest version of iPadOS 17 and that includes the latest version of Safari 17.

[Andrew Hodel]

@Alexey Proskuryakov

17.6.1

I installed it days ago.

Again, this is simply a re-iteration of the two places to check and time problem and that is not how the problem in the WebSocket implementation is resolved.  That is how a work around of fixing in JavaScript again and again works.

It's not needed to do this, approaches of visualization instead of questioning create a result based instead of control based orient.

[Alexey Proskuryakov]

Thank you for the report. Talked to the responsible engineers, we believe that this is the known issue that we track internally, rdar://128224509 (link for Apple employees).

[Andrew Hodel]

Guten Tag!

Your SMTP server didn't accept an email from Gmail when I replied the day you made your final comment, in year 2024!

[Andrew Hodel]

You can cause other browsers to do this by dropping the traffic at the server with iptables.

However, with most browsers other than the iPad removing the drop rule invokes the close event as a packet with a FIN flag is sent from the server if the server already closed the tcp socket by it's timeout and the browser's machine tries to reuse it.

The iPad sits and waits until it has a timeout, and the WebSocket constructor does not allow you to set a timeout.

This is important information.

[Radar WebKit Bug Importer]

<rdar://problem/134821877>

[Alexey Proskuryakov]

This is being tracked as an issue in a system framework outside WebKit, so there will be no further communication here. You can reach out to Apple if appropriate.

[Andrew Hodel]

That's not true, I am reaching out to Apple.

Apple owns the domain webkit.org

https://who.is/whois/webkit.org

[Andrew Hodel]

Also, the Safari browser on iPad chooses to refresh the document if you disconnect and reconnect the WiFi network using the iPadOS menu to force the socket to close and the WebSocket `close` event to fire.

It has done this after 3 disconnect and connect iterations.

[Alexey Proskuryakov]

That would be a different issue, and I cannot reproduce it using iOS 18 beta on https://ws-playground.netlify.app. Please file a new bug report with configuration details and steps to reproduce.