Mobile Tab switching triggers full page reload and error flash

[sabiwara]

Environment

• Elixir version (elixir -v): 1.18.4-erlang-27.3.4.1
• Phoenix version (mix deps): 1.7.21 (also confirmed on 1.8.0-rc.3)
• Phoenix LiveView version (mix deps): 1.0.7 (also confirmed on 1.0.17)
• Operating system: debian-bullseye-20250630-slim
• Browsers you attempted to reproduce this bug on (the more the merrier): Safari on iPhone
• Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: yes

Actual behavior

On a freshly created liveview app, when reopening a liveview tab on mobile after a while (switching to tabs/apps in btw or locking/unlocking), a full reload is triggered, losing client state and flashing an error message.

I managed to consistently reproduce it on an iPhone with the following steps (unlocking is more predictable than switching tabs):

• open the tab
• lock the phone with the side button
• wait ~10s
• unlock the phone

This issue is being discussed on https://elixirforum.com/t/mobile-tab-switching-triggers-full-page-reload-in-liveview-is-this-expected-behavior/71188.

As far as I can tell, older versions of liveview (at least livebeats, released a year ago?) don't seem impacted.

Expected behavior

No full-reload, no error message.

[chrismccord]

I can't recreate this. Do you have server logs? We show a flash error for loss of connection with either "Something went wrong" or "We can't find the internet" depending if the cause is the client connection or server connection. It makes sense that you could see a flash notice after losing connection (the phone sleeps the js thread or cuts the connection), but it's not clear why you are receiving the server error class. Do you have server logs during this? Also by full refresh to do you mean full LiveView re-mount or literal full browser reload of the page? Note that the browser can at any point decide to cycle out the page from memory and that will necessarily require a full re-render and LV itself has its own failsafe refresh if the connected mount repeatedly fails, so there are a couple ways that could happen.

[sabiwara]

Hi Chris 👋
Sorry for the imprecise report, indeed there are two different types of errors here:

1. Something went wrong
2. We can't find the internet

I've been actually getting both, although the reproduction steps I shared above are recreating case 2.
Case 1. appears more randomly and I don't have any consistent way to reproduce it besides randomly switching tabs and waiting. But if I'm not particularly trying, I'd say they're about

The only logs I'm getting for both cases are these, no error:

2025-07-16T11:02:51.931023890Z app[web.1]: 11:02:51.930 [info] CONNECTED TO Phoenix.LiveView.Socket in 36µs
2025-07-16T11:02:51.931100706Z app[web.1]:   Transport: :websocket
2025-07-16T11:02:51.931110907Z app[web.1]:   Serializer: Phoenix.Socket.V2.JSONSerializer
2025-07-16T11:02:51.931148260Z app[web.1]:   Parameters: %{"_csrf_token" => "cSUeWH1IPCEBDgp9PxtsIA9GMgI1PUkYIj-j2zFNSyn6xWYGCrSF_Qyr", "_live_referer" => ..., "_mount_attempts" => "0", "_mounts" => "4", "_track_static" => %{"0" => ..., "1" => ...}, "vsn" => "2.0.0"}

Another info I could share is that I'm located in Japan accessing servers in the EU or US, the latency might be making the issue more likely?

Also by full refresh to do you mean full LiveView re-mount or literal full browser reload of the page?

I assumed it was a full-reload since I confirmed it lost the form state (the email input from the register page generated by phx.gen.auth). To be honest I just confirmed what others have been reporting on the forum thread, but the original issue that lead me in this rabbit-hole was the flash.

It makes sense that you could see a flash notice after losing connection (the phone sleeps the js thread or cuts the connection)

I understand this point, on the other hand it feels like non-optimal user experience: the user has a good internet connection, didn't perform any new action, and is getting displayed an error every time they re-open the tab.

I didn't remember seeing this on older projects (pre 1.0), so I wondered if it was intended or a potential regression.

[spicychickensauce]

As written on the forum, I have this isssue for all my applications.

As far as I can tell, older versions of liveview (at least livebeats, released a year ago?) don't seem impacted.

Livebeats also has the issue for me.
I'm on android, I see the issue in both firefox and chrome. Reproducing it is much harder, as it involves waiting at least 10 - 30m? while in background. Still, I see it quite often on my own applications.

It's not the "something went wrong" error, but re-establishing connection, takes very long, ca. 5s.

I've captured it on video:

2025-07-16.mp4

Video timeline:

1. Firefox, navigating to it for the first time => very quickly loaded
2. Chrome, switching to a it in a backgrounded tab => very slow, full refresh
3. Manual fast refresh on firefox
4. Manual fast refresh on chrome

I'll try to capture server logs on my own application next time, but I don't think we'll see anything interesting there. I think this is 100% a client side issue.

[spicychickensauce]

Here is the server log when it happened. As suspected, nothing interesting there:

15:54:31.028 [info] CONNECTED TO Phoenix.LiveView.Socket in 37µs
  Transport: :websocket
  Serializer: Phoenix.Socket.V2.JSONSerializer
  Parameters: %{"_csrf_token" => "KUhwcw0....YUyL3s", "_live_referer" => "undefined", "_mount_attempts" => "0", "_mounts" => "0", "_track_static" => %{"0" => "http://192.168.178.85:8042/assets/app-6958dfd4c8eee02208df68ed32cbd02a.css?vsn=d", "1" => "http://192.168.178.85:8042/assets/app-d316bf96b8530e7600e3a8fd72ddf315.js?vsn=d"}, "vsn" => "2.0.0"}

Server sees 37µs, but it was again at least 5s on the client

[SteffenDE]

It's almost surely something on the client, server logs won't help here. It's tricky because phoenix.js handles the connection (https://github.com/phoenixframework/phoenix/blob/main/assets/js/phoenix/socket.js), but we also have some code in LiveView. I was able to reproduce the 5+ second delay on an Android device, but it does not reproduce once I try to attach chrome for debugging. It also seems to work fine on my iPhone.

Edit: also seen it happening on iOS when switching to Livebeats from another tab after a while.

[josevalim]

Keep in mind that mobile devices will disconnect web sockets and stop running JS whenever they find appropriate. Depending on your OS configuration, if you are saving battery or not, etc. That would explain the difference in behaviour.

This often means there isn't much we can do because they stop running JS altogether. This issue also happens on regular apps.

[spicychickensauce]

Yeah, we are probably running into battery safer stuff. However,

This often means there isn't much we can do because they stop running JS altogether. This issue also happens on regular apps.

I disagree that we can't do much here. I run a small experiment by adding this to my main js file:

let backgroundedAt = new Date();
document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    backgroundedAt = new Date();
  } else {
    const backgroundedDuration = new Date().getTime() - backgroundedAt.getTime();
    console.log("Was hidden for", new Date(0, 0, 0, 0, 0, 0, backgroundedDuration).toLocaleTimeString("en-GB")
    fetch("/").then((res) => {
        console.log(res);
    });
  }
});

And here are the logs when it happened again, captured via remote chrome debugging:

Server:

13:57:07.945 request_id=GFcFgCyIhxd-zr4AACbC [info] GET /
13:57:08.097 request_id=GFcFgCyIhxd-zr4AACbC [info] Sent 200 in 152ms

13:57:17.672 request_id=GFcFgnBY3yXQ5agAACfC [info] GET /
13:57:17.823 request_id=GFcFgnBY3yXQ5agAACfC [info] Sent 200 in 150ms

13:57:19.640 [info] CONNECTED TO Phoenix.LiveView.Socket in 45µs
  Transport: :websocket
  Serializer: Phoenix.Socket.V2.JSONSerializer
  Parameters: %{"_csrf_token" => "Pjg8BgRHEVN7I3VmRgMrVGwPIzhfJWIaahYc6tU64tM0-DR76byqmCPB", "_live_referer" => "undefined", "_mount_attempts" => "0", "_mounts" => "0", "_track_static" => %{"0" => "http://192.168.178.85:8042/assets/app-4fc4b9a06edf2c81d3bba51c9c86ec28.css?vsn=d", "1" => "http://192.168.178.85:8042/assets/app-b1f64c67300ac60153fadceecd9bed29.js?vsn=d"}, "vsn" => "2.0.0"}

Client:

13:57:06.767 app.ts:160 Was hidden for 00:12:57
13:57:07.270 app.ts:167 Response {type: 'basic', url: 'http://192.168.178.85:8042/', redirected: false, status: 200, ok: true, …}
13:57:18.045 Navigated to http://192.168.178.85:8042/
13:58:16.812 [Violation] 'message' handler took <N>ms
> 13:57:24.607 socket.js:358 [Violation] 'message' handler took 3472ms
> 13:58:11.558 socket.js:358 [Violation] 'message' handler took 362ms
> 13:58:11.913 socket.js:358 [Violation] 'message' handler took 344ms
> 13:58:15.224 socket.js:358 [Violation] 'message' handler took 2900ms
> 13:58:15.731 socket.js:358 [Violation] 'message' handler took 414ms
> 13:58:17.319 socket.js:358 [Violation] 'message' handler took 805ms
> 13:58:17.663 socket.js:358 [Violation] 'message' handler took 324ms
13:57:24.711 [Violation] Forced reflow while executing JavaScript took 643ms

---

Observations:

• JS ran as soon as I unlocked the device
• Server gets the fetch request a couple of ms later
• It took pretty much exactly 10s for the it to decide to do a full refresh
• The WS connection is established immediately after the refresh

So I suspect it should also be possible to reestablish the websocket connection within the timeframe of my manual fetch.
I'll probably just add a location.reload(); inside my backgrounded detector to avoid the issue, but I believe liveview should be able to provide a better solution than that.

Very interesting are those [Violation] messages which might be pointing to the source of the issue. I only saw those after enabling 'verbose' log level in chrome dev tools
But the code in socket.js there is just this.conn.onmessage = event => this.onConnMessage(event), so I don't know how this can take 3.5 seconds.

[josevalim]

Good point. If I remember correctly, we could not trigger a reconnect while in inactive state. But we may have missed something? Can you try doing so by fiddling with the internals?

We also have a somewhat related issue here: phoenixframework/phoenix#5942

[SteffenDE]

It's almost definitely something we do wrong in the Phoenix Socket client related to reconnects.

[rhcarvalho]

Sorry for not being able to contribute much more at the moment. Reading the thread I'd like to suggest using the Performance API to compute durations if we eventually need to in LiveView's JS code.

So instead of

const backgroundedDuration = new Date().getTime() - backgroundedAt.getTime();

Use https://developer.mozilla.org/en-US/docs/Web/API/Performance/now.

This is the equivalent of using a monotonic clock vs wall clock, and is specially relevant on the client side, since we're exposed to a broader variety of quirks compared to a server we control.

(If of any help or inspiration, I contributed related code to Sentry's JavaScript SDK some years ago, e.g., getsentry/sentry-javascript#2441, getsentry/sentry-javascript#2947)

[markdeleon-dev]

Hi everyone,

First, I just want to say how much I absolutely love Phoenix LiveView! The developer experience and performance of the library are incredible, and it's been such a pleasure to build with it. Our app, which operates in a government regulated domain, relying heavily on LiveView, especially with forms for improved interactions, validations, etc.

We're starting to see more of our users experience this issue where switching tabs in a browser or moving away from the app on mobile causes a full page reload, losing form data in the process. Naturally, this has been frustrating for them.

I've been experimenting with potential workarounds, for example: listening for the visibilitychange event in JavaScript, saving the form data when the tab becomes hidden, then pushing it back to LiveView via pushEvent to reapply it on the changeset. This helps preserve data, but unfortunately the LiveView still gets replaced because of the full refresh upon reconnection.

I've also tried creating a hook that listens to disconnected() and reconnected() and applying the same idea as above, but without any success.

I'm curious if there are other strategies that could help here or if there's yet been any effort from the Phoenix/LiveView team to investigate a fix for this yet? I'd love to contribute ideas if there's a safe approach that could preserve LiveView state when users temporarily leave and return.

Thanks again for all the amazing work on Phoenix LiveView, it's truly changed how we build real-time apps!

Environment:
Elixir 1.18.1
Phoenix 1.7.21
Phoenix LiveView 1.0.9
Debian: bullseye-20241223-slim

[markdeleon-dev]

Hi @SteffenDE and @rhcarvalho,

Following up on my previous comment, I’ve tried a hook approach where, on disconnected(), I save the form data to sessionStorage, and on reconnected(), I restore it back into the changeset. This preserves form data on the web, but I’m running into issues on mobile where the state isn’t maintained. I’m not sure if it’s because we are using a React Native WebView, but I’ll keep exploring.

By any chance, have either of you experimented with a similar approach or found any workarounds that could help preserve form state across LiveView reconnects on mobile? Any insights would be greatly appreciated!

[rhcarvalho]

For forms, I rely on LiveView's automatic recovery mechanism, which depends on a deterministic form ID, and a phx-change event.

https://hexdocs.pm/phoenix_live_view/form-bindings.html#recovery-following-crashes-or-disconnects