I have more info, but I’m not sure how significant it is! The connection came good, for no apparent reason. I’m trying to work out why. When comparing two adjacent websocket calls in dev tools (the last failing call, and the first successful one), the only obvious difference is regarding the time of the message. The failing call (says it was stalled for 5.3 days? Actually, hovering over the the time on the failing call, it says 06/01/1970 16:24…):

image1269×306 99.2 KB

image1270×306 107 KB

And the next call, that was successful:

image1272×309 112 KB

Are you using brave by any chance?

Wow, how did you know?! It was in the back of my mind that Brave might be the culprit… I wasn’t seeing the same thing with Chrome

This is the third report I have seen with Brave hanging in the 101 websocket upgrade. Unfortunately it doesn’t appear to be anything on our side and by all things I’ve seen the bits never make it to the server. One person had it happen only when the adguard extension was enabled, but disabling didn’t fix it until they restarted Brave. Both previous reports I’ve seen restarting Brave fixed it, but this looks like some obscure issues squarely on Brave’s side. I have wondered if we are attempting to connect too aggressively for brave, but it is a total guess. If you are able to reliably recreate, you could try instantiating the liveSocket and liveSocket.connect inside a window.addEventListender("DOMContentLoaded", ...)

from a very quick look it seems like Brave proxies websocket when the shield is “up”.. through this code: brave-core/browser/net/brave_proxying_web_socket.cc at master · brave/brave-core · GitHub (and probably else where for the 101 upgrade - NOT a C expert)

there was a recent commit to that file fixing a bug 15715: Properly shutdown our websocket proxy. · brave/brave-core@79783d3 · GitHub, slated for next major brave version (1.26) but totally unknown if it fixes anything related to this issue..

but does sound plausible that some issue exist with brave, especially when using the shield ws proxy.. maybe it can be sporadically reproduced running 100-1k tests with wallaby/chromedriver?

Thank you both, that’s great news (for me!), I thought I was entering a world of pain trying to work out why my app was misbehaving.

I’ll continue to use brave and try a couple of things when it next happens. It appears to only happen when something updates on the server - once in production after I pushed a new release, and a couple of times in dev when the code reloader kicked in. It seems to right itself after about an hour for no reason (yesterday I gave up trying stuff, then came back after 20 mins, and it was all good).

I’ll fire up wireshark next time and see if i can see anything on the wire.

I use Brave get that when I have forgotten to close a div or something. I thought it happened on Edge too though…

I have a control panel which has two domains point at it and I see these a lot in Chrome when I have tabs open with both domains. If all my tabs are 1 domain or the other it’s fine but as soon as there is a mix all liveview pages start to fail.

Just wanted to check in and say I’m still encountering the same endless reloading “websocket connection is closed before connection is established” issue.

I’m using Brave 1.28.105 on MacOS 11.5.1 and looking at the source code for this version of Brave on Github, the previously linked PR’s websocket fix code is present in this version of the browser but it doesn’t seem to make a difference.

I still get the Websocket error with or without Brave’s “shields” up or not.

Hi @jakemauer, that’s interesting, I’ve not had it happen to me since I posted. For me it’s been really intermittent. Is it happening for you all the time?

I’m on the same version of Brave, but on linux