Phoenix + LV website keeps auto-refreshing in production

Hi everyone,

I have a weird bug whith a website built with Phoenix + LV: it keeps auto-refreshing every 30 seconds or so, but only for certain people/browsers.

I use Brave and I constantly have a little thing spinning on top right of my window. If I fill in a form, I know the data I put will be gone in 30 seconds max. This doesn’t happen on Firefox, though.

Unfortunately, a customer has the same problem as myself, but with every single browser. So I can’t even reproduce the bug, and the network devtool has been of no help.

Any idea what that could be? A misconfiguration issue maybe?

I sounds like the live view process is crashing and restarting.
Can you look at the application logs to see if you can find any LV related errors/exceptions?

Or you can use liveSocket.enableDebug() in the Console …maybe you see the crash…
Debugging Client Events

1 Like

There are known issues with brave and their websocket handling. That may be the reason.

4 Likes

Thanks for the reply.
But nope, no crash, no restart, just a new request exactly as if I had refreshed the page…

It sounds like a misconfiguration, but it’s hard to know without seeing the code of say the page and everything related where it’s occurring on and the configuration code as well.

My guess is it sounds like something is crashing or timing out from a function call (if all of the configuration is correct). Or in the case of the form, the html is off a bit or the form not configured correctly (perhaps in the validation logic). Are you using heex?

Could there be some type of call to the database, or some type of logic, perhaps a webhook, for a person that is invalid for some people and not others? Like whether or not someone has an account or has created certain data or not? A situation like that could cause it to crash for some people and not others.

Could be the simplest little thing. I don’t suspect it’s something with Brave only because Brave appears to work just fine with Metamorphic and I feel like the issue you’re experiencing is something I would encounter too and have encountered when little bugs or misconfigurations were present. :blush:

Okay :joy: great foot in mouth moment, same thing appears to happen to me with Brave too. I guess I never let it sit for 30 seconds with data in the form.

2 Likes

Thanks for this detailed answer, and for having checked!

Thing is, I am having the issue with Brave, not FF, but a customer of ours tried every browser he had (on Windows), and they all had the same behavior.

Also, I don’t see any evidence of anything crashing. I enabled the websocket debug in JS of course, and got nothing.

1 Like

@f0rest8 do you have the same 30 secondes timespan? That means there must be a default somewhere that can be changed.

I witnessed similar behaviour in production in one of my liveviews, in my situation the culprit was a database query inside of the mount function which was taking too long. When the liveview did not respond in time, it hit a timeout and assumed the server was unavailable, restarting the request. Of course, this was never able to complete as the data did not change between requests, leading to an infinite reload. I did not investigate where the timeout was coming from or how to configure it, instead I handled my problem by loading the data asynchronously and then sending a message over the channel when the data is ready. Depending on your needs this may be an appropriate solution.

I would suggest starting by examining any database queries you’re doing, and if you can test with your production data, then examine what data this particular customer is loading.

4 Likes

For me I notice Brave wants the manifest-src set for the csp policy. I’ll update that later and report if it fixes it or not.

1 Like

I can check more on this later today when I sit down to work, sorry just taking glances on my phone at the moment. :blush:

Update
Okay, I updated the csp and I haven’t been able to reproduce the reload anymore, both in production and in development. So, I’m not sure if the csp lacking the manifest-src was causing the issue for Brave or not, but it appears to be fixed.

I’m thinking that when I checked earlier on my phone, there may have been an internet connection issue that caused the socket to reload as it was disconnected during that brief blip in service (that’s my guess currently).

I tested with Firefox and Brave in production and development. Could it be that the person reporting the errors across browsers has spotty internet service?

Also, if it has to do with form recovery, then you can try checking this out from the docs:

Note: if you want to see form recovery working in development, please make sure to disable live reloading in development by commenting out the LiveReload plug in your endpoint.ex file or by setting code_reloader: false in your config/dev.exs. Otherwise live reloading may cause the current page to be reloaded whenever you restart the server, which will discard all form state.

Have you seen this thread on Brave and WebSockets? It’s not the exact case you’re experiencing but Chris McCord mentions:

If you are able to reliably recreate, you could try instantiating the liveSocket and liveSocket.connect inside a window.addEventListender("DOMContentLoaded", ...)

Not sure if that will help or not.

1 Like

I see my liveview page load on tab switching , i use temporary assigns in my view any idea what could be causing it ?

Thanks a lot for this in-depth response.

I am pretty sure this is not related with a database query, but I sure will try this CSP thing (I’m surprised this is not a default enabled by plug :put_secure_browser_headers btw).

As for the reason, it might be that this person has a corporate firewall that breaks WS connections.

I let you all know when the fix has been tried :slight_smile:

1 Like

For what it’s worth, I use plug_content_security_policy to make setting the csp easy. It works great and makes setting/updating the csp really easy from my experience.

Although, I’m pretty sure sobelow doesn’t see it (haven’t tested with setting it directly in the endpoint), so you’ll see warnings from sobelow if you’re using sobelow to check your app’s security.

2 Likes