Phoenix livereload / liveview connection issue

masterkain · May 31, 2021, 7:08pm

I started a new liveview project on Erlang/OTP 24, Elixir 1.12.1, and with the latest liveview packages.

My problem is that both livereload and liveview websocket connections timeouts and I have basically a vanilla project.

It seems to work for a small amount of time if I switch to incognito mode or often if I restart the server.
I triple checked all the configuration and everything’s fine.

Anyone encounters this issue? I’m going crazy with the development.

chrismccord · June 1, 2021, 12:11pm

Are you using Brave by any chance? We had a couple reports from Brave users where web sockets would be pending on the 101 upgrade. Everything that I’ve seen pointed to a brave issue as the websocket upgrade did not appear to be sent to the server.

masterkain · June 1, 2021, 12:22pm

hello, yes, I’m using brave :\

however occasionally I have the same issue on Opera, as I’ve tried switching browser.
I’m trying going back to Chrome then, thanks.

chrismccord · June 1, 2021, 12:25pm

The last report I got only happened when using the adguard plugin with Brave, and it required a full brave restart to fix. I honestly don’t believe it’s anything we can fix on our side.

chrismccord · June 1, 2021, 12:28pm

I would be curious to see if disabling live reload fixed it, where maybe two websocket connections to the same host borked Brave for some reason. That or delaying the websocket connection until DOMContentReady if Brave has an issue with how aggressively we try to connect on js load, but I am completely spitballing.

MRdotB · August 27, 2021, 12:03pm

I got the same problem on brave browser. Using https in dev solved the issue.
I am also using a custom domain myproject.local and some *.myproject.local instead of localhost not sure if it matter.
I used mkcert but it should probably work using the mix task Using SSL — Phoenix v1.5.12

iwarshak · June 17, 2022, 2:12pm

Same issue here. I have a Brave window open, and my http://localhost tab is continually reloading, while the same URL being accessed via https://xxxxxxxx.ngrok.io is working fine.

Hard to say if it’s a hostname issue or an http/https issue with Brave, but using grok definitely fixed it for me.

chrismccord · June 17, 2022, 3:52pm

for posterity, Brave has an ongoing and unaddressed websocket issue with multiple webservers/frameworks WebSocket sometimes fails to reconnect until browser restart or website access from incognito mode · Issue #15410 · brave/brave-browser · GitHub

wanton7 · June 17, 2022, 4:53pm

According to [Brave Shield] - Brave's unbreak list directly identifies you as a Brave user · Issue #10165 · brave/brave-browser · GitHub you can detect if browser is brave with typeof navigator?.brave?.isBrave === 'function'. Maybe show a warning when Brave is detected if user wants to continue?
It doesn’t seem like fixing WebSocket support is not high on Brave team’s list or they would have fixed it already. Kind of sad since many web sites rely on WebSocket support for realtime events.

marcelfahle · December 27, 2022, 6:19am

I deal with this almost daily on localhost (with ngrok it’s a bit better), but it seems like there’s finally some movement:

github.com/brave/brave-browser

WebSocket sometimes fails to reconnect until browser restart or website access from incognito mode

opened 10:22AM - 21 Apr 21 UTC

davidhq

priority/P3 OS/Desktop

## Description Websocket sometimes fails to reconnect. Only solution is to… access the website in incognito mode or restart the browser. **WebSocket is closed before the connection is established.** ## Steps to Reproduce 1. have a tab open 2. close the laptop lid, reopen and reconnect to wifi 3. websocket stays disconnected and keeps retrying to reconnect with no success ## Actual result: websocket keeps trying to reconnect but it is not able to ## Expected result: Should reconnect ## Reproduces how often: Intermittent issue ## Brave version (brave://version info) Latest: Version 1.23.71 Chromium: 90.0.4430.72 (Official Build) (x86_64) ## Other Additional Information: ## Miscellaneous Information:

and

github.com/brave/brave-browser

closing websocket after server received headers but before client.readyState == OPENED causes subsequent connections to hang

opened 07:46PM - 16 Dec 22 UTC

binary-person

OS/Desktop

## Description this issue is related to #15410 and #19123. The timings of the server and browser causes this issue to appear haphazardly and is normally difficult to reproduce reliably. This is what happens: 1. client makes a connection to the server 2. server receives client headers and establishes the connection 3. client.readyState is still OPENING 4. closing the websocket during this window of OPENING and OPENED causes the close packet to never be sent 5. subsequent websocket connections to the same server hang; server never receives those connections ## Steps to Reproduce We first setup the environment to reproduce this bug. First we setup the server. Paste the following into `server.js` and run `npm install ws` and then `node server.js` ```js const { WebSocketServer } = require('ws'); const server = new WebSocketServer({ port: 8080 }); server.on('connection', (socket, req) => { console.log(req.httpVersion, req.url); console.log(req.headers); socket.on('message', (data => { console.log(data.toString()); socket.send('received!'); socket.close(); })); setTimeout(() => { if (socket.readyState === socket.OPEN) { console.log('timing out, closing'); socket.close(); } }, 10000); socket.on('close', () => { console.log('closed'); }); }); ``` Open Brave, go to `http://127.0.0.1:8080`, open dev tools, then paste the following into the console ```js function testLatency() { const client = new WebSocket('ws://127.0.0.1:8080/'); date = Date.now(); client.onopen = () => { console.log(Date.now() - date); client.close(); }; } function tryAndBreak(latency = 2) { const client = new WebSocket('ws://127.0.0.1:8080/'); setTimeout(() => { console.log(client.readyState); client.close(); console.log(client.readyState); }, latency); } ``` Now to reproduce this bug: 1. run `testLatency()` multiple times. I got 5ms on average 2. this means we need to choose a delay between 0 and 5ms before we close the websocket. I'll choose 3ms. 3. run `tryAndBreak(3)` until two conditions occur (I reproduced this issue on every first try): 1. this gets printed: `WebSocket connection to 'ws://127.0.0.1:8080/' failed: WebSocket is closed before the connection is established.` 2. server receives the connection and prints out client headers BUT does not print "closed" 4. trying to run `testLatency()` again will result in the connection hanging. The server also doesn't receive the connection. ## Actual result: On step 3, server never receives the close packet, and subsequent connections hang. ## Expected result: On step 3, server does receive the close packet, and subsequent connections work fine. ## Reproduces how often: Very easy, if you get the timings right. ## Brave version (brave://version info) Brave | 1.46.144 Chromium: 108.0.5359.128 (Official Build) (arm64) -- | -- Revision | 1cd27afdb8e5d057070c0961e04c490d2aca1aa0-refs/branch-heads/5359@{#1185} OS | macOS Version 13.0.1 (Build 22A400) ## Version/Channel Information: - Can you reproduce this issue with the current release? yes - Can you reproduce this issue with the beta channel? N/A didn't test - Can you reproduce this issue with the nightly channel? N/A didn't test ## Other Additional Information: - Does the issue resolve itself when disabling Brave Shields? no - Does the issue resolve itself when disabling Brave Rewards? no - Is the issue reproducible on the latest version of Chrome? no (even though "WebSocket is closed before the connection is established" gets printed, server still receives the close packet, and following connections work fine) ## Miscellaneous Information: I hope the reproducible steps help facilitate a fix for this issue, since this looks like it has been a problem for more than a year...