taoensso / sente

Realtime web comms library for Clojure/Script
https://www.taoensso.com/sente
Eclipse Public License 1.0
1.74k stars 193 forks source link

socket_ gets replaced by plain object in Firefox #343

Closed Sardtok closed 1 year ago

Sardtok commented 5 years ago

Using 1.13.1 at the moment, and I keep seeing a few errors in Firefox. Works fine in Chrome, Edge and iexplore11. The main issue, is that at some point in Firefox, the socket_ atom no longer references a WebSocket object, but a plain JS object with two fields: listeners and websocket.

Related to this is an error I see in the console upon establishing the connection: this.listeners.onopen is not a function (called internally by Firefox as far as I can tell). At this point the socket_ points to a WebSocket object directly.

If there are other issues in the application, like the user session timing out without us being able to refresh their token, we disconnect the websocket. In Firefox we cannot re-establish the connection, due to the change in object type.

When we try to call chsk-disconnect! we get an error that there's no close function in the object, as it doesn't reference the WebSocket directly. This screws up the state. We can probably throw in a try around the call to chsk-disconnect! to make sure or state doesn't end up broken, but it seems like there's a bug in Sente on Firefox or Firefox itself (I'm currently on FF 67.0.4)

ptaoussanis commented 1 year ago

@Sardtok Hi Sigmund, apologies for the long delay replying.

I'll be focusing some renewed attention on Sente shortly. Is this issue still relevant? Do you have any updates to share from your end?

Thanks

ptaoussanis commented 1 year ago

@Sardtok Hi Sigmund, apologies for the long delay replying!

Closing this as part of issue triage since this is referring to a very old version of Sente. Since there haven't been any other reports on this, I'm assuming the issue is no longer relevant?

The current code for creating client sockets is here and the only place it's mutated here - both of which look okay to me.

I may be missing something though! Please feel free to re-open if this is still relevant, and I'll investigate further.

Again, apologies for the long delay.

Sardtok commented 1 year ago

Sorry for the wait on a reply. This may very well not be relevant any more.

At the time we fixed it by simply catching any exception thrown when disconnecting. That application has since been moved to a simple REST interface instead of WebSockets, so for us specifically, it's not an issue any longer.

ptaoussanis commented 1 year ago

No worries, thanks for the update 👍