I notice that my liveview app resorts to longpoll when accessed via chrome browser.
But on firefox, websockets work fine.
Am I missing some configuration?
LiveView sets a key in session storage when it resorts to longpoll and uses longpoll when that key is set. This might happen due to a (dev) server restart when the connection is lost for a brief time.
That might be the issue. Clear the session storage for the domain and see if it solves the issue.
4 Likes
You sir, are a life saver!!! THANK YOU!
Spent way too much time trying to sort this out 
1 Like
Sadly, once you fall back to longpoll, it never goes back to WebSocket—at least in my experience.
If you want to avoid that, you can use a LiveView hook to store in localStorage whether the connection previously supported WebSocket. Then, on reconnect, if that key is present, you can trigger a full window reload.
It’s your decision: either keep the user connected without reloading, or do a quick refresh.
In a system with 200,000 connected users, if your reverse proxy restarts or there’s a network failure, you’ll “suddenly” start seeing 200,000 HTTP requests per second.
1 Like
Afaik there is an exponential backoff mechanism in place incl randomizer to prevent such thing. Not sure so you might want to research (and file a request if it’s not there)
Maybe is there something new…
My last update on this matter was this comment and a year has already passed.
The way it works is that Phoenix’s JavaScript code (the portion that deals with Phoenix Sockets, as LiveView is built on top of that) will store a key in the browser’s Session Storage, which lasts until the tab is closed.
