LiveView is reloading on iOS devices

Hello everybody,

I have a web app where I have a multi step registration process done in LiveView…

It was working great until recently where some iOS users are complaining about the process being broken.

The problem occurs at one step when the app is sending a one time verification code. When the user switch to his email app/client to check for the code and come back to the web app the LiveView reload and the process go back to the first step…

I tested on an iOS device (quite old iPhone 7 but with iOS 15.1) and the problem happens either with safari or chrome.
On my Android phone everything is still fine.

I’m currently unable to check for the servers log and I know that without much information it could be difficult to tell anything but I want to know what could cause this problem?

I remember that I already hear about LiveView disconnecting on some devices but I have no more clue.

Thank you very much for any direction…

This may be the iOS disconnecting all web sockets when on background to save energy. The solution is to make sure the app can go back to that step even on reload. On a two step authentication, I usually store the success of every step in the session.


My man! :smiley:
Thanks José for your time!

I was thinking if I need to persist the step (basically the email/code couple) on the database which will need to make a migration/schema/etc. altogether…
But using the session is actually the correct way I guess…

I’ll try to look how to do it… I forget how read/write from the session :sweat_smile:

Unless it’s just a matter of storing assigns in the conn rather than the socket?

I think you should create LiveView app so that it can handle WebSocket disconnects anywhere in the app. Otherwise users will have bad experience when WebSocket disconnects and it will happen for some users for sure.

1 Like

Not quite, there is put_session in the conn. If you are using LiveView, the trick is to use phx-trigger-action to submit a page where you then validate the credentials/form and persist to the session.



I agree with that, I’ll try to read and learn more about that pattern… We can check for when the WebSocket is connected with connected? but is there a way to check for disconnection in the server side?

Oh, yes, simply that of course…

I didn’t hear about phx-trigger-action
But since (I quote from here):

Once phx-trigger-action is true, LiveView disconnects and then submits the form.

Isn’t this will explicitly switch back to HTTP reload rather than LiveView refresh?

The LV will die on disconnect, you can probably pubsub to something to see the event or write a hande_info() callback and try to save some kind of recovery data to the server then but it is probably preferable to encode your recovery data into the browser and either use:

In any case, careful that you sanitise the data coming back. Your form will be easily editable, the session can be made more tamper resistant. You also don’t have to encode “user_id=1” into the form, you could encode the data similarly to how Fly talks about using the session.

1 Like

Like @soup said LV session will die on disconnect so you need to give important state back to new LV instance when live socket reconnects. This means you can only keep state in the LV session that is not important and can be recreated from database etc. What you need to do is save important state to browser. This can be state in the query string or you can use LiveSocket params to return state from JavaScript variables for example. Let’s say you open a panel in the page then you save state to query string that the panel is open. Then if you get a WebSocket disconnect new LV session just reads that the panel needs to be open from query string. I think you should be able to easily check if everything works on reconnect by just doing liveSocket.disconnect() and then liveSocket.connect() from browser console.

Another important thing is that LiveView is designed so that it can connect to a different server on reconnect. So if you connected to server A in your first LV session then get a disconnect then reconnect you could connect to server B. There aren’t any problems with this because important state is coming from the browser on reconnect.