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!
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

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.

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.

Hello,

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:

• phx-auto-recover and a form Form bindings — Phoenix LiveView v1.2.5 or
• browser session/cookie/localstorage: Saving and Restoring LiveView State · The Phoenix Files
• Or sometimes you can just encode the recovery data into the URL and handle_params() depending on what you are working with (you could encode some recovery token and load progress from the db for example).

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.

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.

Hi
We have the same problem, but for us it’s on a page with an payment-iframe that we don’t control.
On the payment page we load the payment iframe.

• The user fills out the payment and presses the pay button
• The payment is authorized at the bank
• The user is required to verify with 3D Secure (which for many people opens an app)
• When done verifying in the app, the user returns to the browser and the browser reloads and loses the chance for the callback from the payment iframe.

I’m not coding this, and I haven’t been a big part of the bug-hunting, so I might have missed a step, but this should describe the key problem. The page reloads while we’re waiting for a callback.

As a “quick” solution we’ve moved to a static page on the payment page, but it just feels wrong. We chose LiveView for a reason, and we want to stick to it, but we can’t see a way out of this.

I’ve witnessed some of the same behaviour on mobile. Most of the time there has been a phx-auto-recover which allows the state to be populated, but occasionally, there is a full page refresh. I haven’t figured out how to deal with it in general, but billing pages should probably be treated more carefully.

For pages such as billing, there are a few options:

1. Store the state of the user in ETS with the user-identity stored as a cookie clientside. Need to be careful storing anything more client-side as that can be manipulated for billing which may end up being an issue. On liveview mount, you can check for the state and do the appropriate action.
2. Use a static page. I don’t think this feels wrong at all. For instance, for login and pricing pages, I’m not using liveview. I don’t like any user state to manipulated by JS, so it is in a signed https-only cookie which can only be set thru server headers. I did attempt to use liveview initially, but after some thought, it was pointless.