Bug 245350 – Websocket disconnects in Safari when user switches out to another app when experimental feature "NSURLSession WebSocket" is turned on

• Status: NEW
• Component: Page Loading

When user switches out to another app while connected to a Websocket connection on Safari, Websocket connection will lost if experimental "NSURLSession WebSocket" is turned on

Listing out the steps:
1) Websocket connection successful on Safari Browser
2) User switches out to view another application
3) User switches back to Safari Browser (web connection gets disconnected)

To rectify, user have to go to Settings -> Safari -> Advanced -> Experimental Features -> Disable "NSURLSession WebSocket"

After disabling "NSURLSession WebSocket" 
1) Websocket connection successful on Safari Browser
2) User switches out to view another application
3) User switches back to Safari Browser (web connection remains connected and working as intended)


This issue does not happen in other browsers such as Chrome, Firefox, Edge..

(In reply to chris.ng.hs.code from comment #0)
> When user switches out to another app while connected to a Websocket
> connection on Safari, Websocket connection will lost if experimental
> "NSURLSession WebSocket" is turned on
> 
> Listing out the steps:
> 1) Websocket connection successful on Safari Browser
> 2) User switches out to view another application
> 3) User switches back to Safari Browser (web connection gets disconnected)
> 
> To rectify, user have to go to Settings -> Safari -> Advanced ->
> Experimental Features -> Disable "NSURLSession WebSocket"
> 
> After disabling "NSURLSession WebSocket" 
> 1) Websocket connection successful on Safari Browser
> 2) User switches out to view another application
> 3) User switches back to Safari Browser (web connection remains connected
> and working as intended)
> 
> 
> This issue does not happen in other browsers such as Chrome, Firefox, Edge..


For testing the above, you can use https://www.piesocket.com/websocket-tester and press Connect button

[Alexey Proskuryakov]

I'm nearly certain that I saw other bugs filed about this a year or so ago, but cannot find them now.

Just wondering if there’s any further info I need to provide, please do let me know if there’s any solution for this, thanks for your help

[youenn fablet]

<rdar://90925089>

[youenn fablet]

<rdar://100378735>

hi [e-mail], is the link you posted supposed to be some information related to this issue? Can't seem to see or find anything on google with those links you posted

[Alexey Proskuryakov]

The rdar links are only useful to Apple employees, so that we could correlate bugs.webkit.org with internal discussions.

We are not asking for any additional information at this point, but thank you for checking!

I would recommend handling disconnects in your JavaScript code, and reconnecting. Disconnects can happen for a lot of reasons (such as user going out of cellular coverage zone, or server side problems), so doing this will increase reliability of your website in all browsers.

Thanks Alex for the reply. Yes, for scenarios where there are no connection we will show the user that they have been disconnected and they will have to retry. But however where there isn’t any connection issues, the websocket should be able to remain connected and receive the information when switched out to other apps, but however for Safari, our users have to turn off the experimental feature to be able to work.

 All the other browsers(edge, chrome, Firefox..) are working fine and able to receive the information without any particular settings needed and they are still able to get the websocket information when user switched out to another app to send trigger the websocket event.

Just wondering if this is still work in progress and to be resolved by the apple developers or it’d be a limitation specifically only for IOS safari 15/16, will help for developers to implement instructions to disable the experimental feature.

> Just wondering if this is still work in progress and to be resolved by the
> apple developers or it’d be a limitation specifically only for IOS safari
> 15/16, will help for developers to implement instructions to disable the
> experimental feature.

Just to further explain, in our implementation the users have to trigger a websocket event in another application. As they will be switched out from Safari browser app to the other application, the websocket connection will be lost and there's no way the websocket in Safari can receive any message if its disconnected.

So if issue is not to be worked on in near future, we will have to put in instructions specifically for Apple IOS users (Safari 15/16) to resolve the issues through the settings on their device to disable the NSURLSession Websocket.

[Alexey Proskuryakov]

Can you please clarify why you cannot implement the suggested workaround, which will be beneficial in all browsers?

Hey Alexey, 

In a summarized use case:
1) In Safari web socket is connected
2) User gets directed to another mobile application to trigger an event in websocket, event message triggered on mobile application *this event will only get triggered once
3) user gets back to Safari, websocket is disconnected, event that is triggered in point 2. is already lost. Reconnecting to the websocket room will not have any effect as point 2 has already happened

(In reply to chris.ng.hs.code from comment #11)
> Hey Alexey, 
> 
> In a summarized use case:
> 1) In Safari web socket is connected
> 2) User gets directed to another mobile application to trigger an event in
> websocket, event message triggered on mobile application *this event will
> only get triggered once
> 3) user gets back to Safari, websocket is disconnected, event that is
> triggered in point 2. is already lost. Reconnecting to the websocket room
> will not have any effect as point 2 has already happened

And yep, if its disconnection due to network issues, we can prompt the user to trigger a reconnection, and perform the above flow again. But that only works for the us based on the above flow if the websocket remains connected to receive the message in point 2, else the issue persists.