278313 2024-08-19 07:21:17 -0700 WebSocket close event is not fired when close() is called. 2024-08-29 13:48:37 -0700 1 1 1 Unclassified WebKit WebKit Misc. Safari 17 iPhone / iPad iOS 17 RESOLVED MOVED https://bugs.webkit.org/show_bug.cgi?id=274003 InRadar P2 Normal --- 1 andrewhodel webkit-unassigned achristensen ajuma ap webkit-bug-importer oldest_to_newest 2053705 0 andrewhodel 2024-08-19 07:21:17 -0700 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. 2053725 1 ap 2024-08-19 08:44:26 -0700 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? 2053735 2 andrewhodel 2024-08-19 09:13:24 -0700 @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. 2053806 3 ap 2024-08-19 12:09:18 -0700 I add the WebKit issue to See Also; others are Apple internal. My question still stands, which OS version are you observing this with? 2053817 4 andrewhodel 2024-08-19 12:39:11 -0700 @ Alexey Proskuryakov That's already specified in the bug's fields. 2053824 5 ap 2024-08-19 12:49:18 -0700 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. 2053829 6 andrewhodel 2024-08-19 13:02:22 -0700 @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. 2053842 7 andrewhodel 2024-08-19 13:22:25 -0700 @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. 2053891 8 ap 2024-08-19 14:43:25 -0700 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). 2055158 9 andrewhodel 2024-08-24 15:16:59 -0700 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! 2055789 10 andrewhodel 2024-08-27 18:00:41 -0700 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. 2055790 11 webkit-bug-importer 2024-08-27 18:01:15 -0700 <rdar://problem/134821877> 2056028 12 ap 2024-08-28 12:57:40 -0700 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. 2056053 13 andrewhodel 2024-08-28 13:47:42 -0700 That's not true, I am reaching out to Apple. Apple owns the domain webkit.org https://who.is/whois/webkit.org 2056340 14 andrewhodel 2024-08-29 12:25:52 -0700 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. 2056364 15 ap 2024-08-29 13:48:37 -0700 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.