Safari dropping web socket connection due to inactivity when page not in focus

[twistedpixel]

You want to:

• report a bug
• request a feature

Current behaviour

Not sure if this is a known issue (I tried searching but found nothing). Safari for Mac appears to be silently dropping websocket connections due to inactivity/idle if the page/tab is not in focus.

Steps to reproduce (if the current behaviour is a bug)

Make Safari tab/page not in focus; log websocket events.

Expected behaviour

Websockets should be kept alive via the heartbeat functionality. Not seeing this behavior in other browsers so unlikely to be my code.

Setup

• OS: Mac OSX 10.12.4 (16E195)
• browser: Safari 10.1 (12603.1.30.0.34)
• socket.io version: 1.7.3

Other information (e.g. stacktraces, related issues, suggestions how to fix)

Is this possibly some sort of power-saving feature that is overriding/ignoring the heartbeats?

[twistedpixel]

Running server with DEBUG=* shows the following:
socket.io:client client close with reason ping timeout +0ms
socket.io:socket closing socket - reason ping timeout +0ms

which I presume means that Safari closed the connection, not the socket server or client instance. However the strangest thing is that I've noticed Safari sometimes reconnects around 30 seconds to 1 minute later but other times it does not and stays disconnected until the page is brought to focus. It's incredibly frustrating to try and debug with such inconsistent behavior.

[twistedpixel]

It seems that sometimes it sporadically reconnects much later (like 10 minutes). Again, completely inconsistent under identical testing environments.

[darrachequesne]

@twistedpixel the reconnection delay is exponential (that is, something like: wait 500ms, try reconnect, wait 1000ms, try reconnect...) (source), so that may explain the behaviour.

How about forcing to reconnect when the window gets the focus again?

window.addEventListener("focus", () => socket.connect());

It may be related to primus/primus#348.

[twistedpixel]

Thanks for the info but the main issue is that I need the web socket permanently connected because it's used to send alerts to the user while they're away. Therefore window focus to reconnect isn't ideal.

I think it's actually something more problematic specific to my machine/install anyway. I noticed the behaviour originally on my iMac so I decided to just wipe my MacBook with a fresh version of Safari and I'm not seeing the behavior there at all. I left a tab minimised for a whole day and it didn't disconnect once. I therefore tried going back to the iMac and removing all internet plugins and disabling all extensions but still I saw this behavior.

Apple doesn't seem to provide any way to reinstall Safari completely other than deleting its preferences and certain other files. Or wiping the machine. Part of me wants to just start fresh but the developer in me would hate not knowing what the cause is.

[twistedpixel]

Actually, to your point about the exponential re-connects: surely the first re-connect would, as you say, be around 500ms after disconnect... so why would the server ignore it? There must be something preventing it from firing the re-connect.

It's a bit weird because if I stick a socket.connect() in the disconnect event, it connects again just fine. It has to do it every few minutes but still it does so without fail. So I'm completely puzzled as to why a re-connect isn't happening! I'll do a bit more digging and see if I can figure out why.

[llaakso]

This is typical browser behavior nowadays, even on desktops, unfortunately.

[twistedpixel]

I think I know what's happening. Safari is indeed the problem.

I think all browsers cap the setTimeout and setInterval values at 1000 when the tab is not in focus. Safari - stupidly - caps it at 1000 and does something like exponentially adding a delay that results in each iteration taking doubly as long as the last. This is why the connection dies; socket.io's internal timeouts are being delayed/dropped, explaining why reconnects aren't happening when they should.

So basically, Apple has decided to go against the grain, as usual, resulting in a poor user experience. They're really good at this these days.

I haven't discovered why it's affecting the iMac and not the MacBook (I'd have expected the reverse) but I'll keep testing and see if I can pinpoint the exact reason.

[lpinca]

@twistedpixel it's not only Safari. See http://blog.strml.net/2017/01/chrome-56-now-aggressively-throttles.html

In Primus we worked around the issue by reversing the direction of the heartbeat messages (primus/primus#534).

[twistedpixel]

@lpinca The entire time I was trying to figure out this issue I was wondering that very thing. Thanks for the info! I have been looking at Primus but I didn't want to have to refactor my entire code base so soon. Seems it could be worth the effort though.

[lpinca]

@twistedpixel my point is that the same can probably be done in Engine.IO so there is no need to migrate to Primus.

[twistedpixel]

FWIW, Safari Tech Preview does not seem to be affected by the additional throttling. Perhaps Apple reversed their decision. It's still throttling to 1000ms but doesn't seem to be adding anything further.

[username99987]

I am experiencing the same issue on iOS 12 Safari. If I re-open my safari, the websocket connection is gone. Is there a clean workaround to keep the socket alive?