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

davidhq commented 3 years ago

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

have a tab open
close the laptop lid, reopen and reconnect to wifi
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:

davidhq commented 3 years ago

It happened again now, latest screens:

csadai commented 3 years ago

+1

davidhq commented 3 years ago

It happens all the time to me recently, too bad nobody acknowledges this problem for more than a year now :/ Such a core functionality and browser otherwise works ok

davidhq commented 3 years ago

So ... today I tried using Firefox after some time, and surprise: websockets there are even more broken!

So is this tech doomed? See this: https://stackoverflow.com/questions/14140414/websocket-was-interrupted-while-page-is-loading-on-firefox-for-socket-io/68260938

Why Brave and (even more so) Firefox teams don't care about this even one bit and assign lowest possible priority to this or entirely ignore the issue?

What is the working websockets alternative once can use in the same way? There probably isn't any... so many websites use websockets for crucial parts of their functionality and this means that one third of the internet is half broken in some of the biggest browsers... wtf!

davidhq commented 3 years ago

https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c24ae4d9d96

I would encourage every team to explore SSE. Perhaps it doesn’t completely cover your use case, or maybe it’s the missing piece of your HTTP/2 compliant stack you’ve been waiting for. Either way, it’s fun and lightweight, and as we start seriously considering parting ways with our dear old friend WebSockets, it’s time to start calling up older friends to see what they have to offer.

?

rebron commented 3 years ago

@davidhq Do you have an issue filed here: https://bugs.chromium.org/p/chromium/issues/list This is not an issue that we'd address separately from the chromium team.

davidhq commented 3 years ago

@rebron no, the issue is not in that list and the problem does not happen in Chrome, it's a Brave issue

davidhq commented 3 years ago

You somehow broke the core functionality which is working in Chromium

wanton7 commented 3 years ago

This seems to be a big issue for things that are run though websockets only like Phoenix LiveView https://elixirforum.com/t/websocket-is-closed-before-the-connection-is-established/40481/5

chrismccord Creator of Phoenix 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", ...)

chrismccord commented 2 years ago

@rebron I'm getting more reports about this affecting Phoenix users, and I'm wondering if you were able to verify this is actually reproducible on chromium? I see the repros-on-chromium and awaiting-chromium-upstream labels have been added here, but I have yet to hear about anyone hitting this kind of issue on chrome. Narrowing down where this might be occurring would be really helpful. Does Brave implement any websocket specific handling or security checks? I've long wondered if we connect too aggressively and trip some brave threshold, but I have no evidence to suggest that's the case. In any case, I would love see if we can at least pinpoint whether this is on the Brave or Chromium side. All reports point to Brave at the moment. Thanks!

davidhq commented 2 years ago

My guess would be that they think many other issues should get priority or that this is not happening / is not important.

The nature of this issues is that it happens once every few months perhaps, sometimes more, under right conditions.

Not trying to be negative but indeed I have stopped utilizing Brave for anything because such unpredictable issues when you have to stop and think if the problem is my code or not (it is not)... just not worth it.

For developers of Elixir / Phoenix it must be even more frustrating because on the outside it looks like their system is not reliable when it's browser's fault. If they in turn point a finger to chromium then it shows lack of organization or responsibility over there.

I hope they make it work though :) Would be good for everyone.

Thireus commented 2 years ago

macOS 12.0.1 Intel here. Such a weird issue indeed with wss:// completely stuck with "WebSocket is closed before the connection is established" despite restarting the app several times. Private Window seemed to work just fine though.

Had that issue with: Version 1.32.81 Chromium: 95.0.4638.54 (Official Build) beta (x86_64)

Just upgraded to a new release, the issue is still there but less frequent now: Version 1.32.84 Chromium: 95.0.4638.54 (Official Build) beta (x86_64)

Give it a try: https://cryptowat.ch/charts/POLONIEX:SHIB-USDT

Websocket_Issue_Brave

davidhq commented 2 years ago

macOS 12.0.1 Intel here. Such a weird issue indeed with wss:// completely stuck with "WebSocket is closed before the connection is established". Private Window seems to work just fine.

Had that issue with: Version 1.32.81 Chromium: 95.0.4638.54 (Official Build) beta (x86_64)

Just upgraded to a new release, the issue seems to be gone (at least for now): Version 1.32.84 Chromium: 95.0.4638.54 (Official Build) beta (x86_64)

we commented almost at the same time...

so for you did it actually happen on Chrome and not on Brave?

For me in 2 years with this issues it never happened in chrome... or rather MAYBE once... in Brave every few weeks, sometimes days, sometimes months.

Surely it must be complicated and elusive and a lot of work for maintaners...

just pointing out again after 6 months that it's a rather nasty issues (at least on Brave) and it seems many others are experiencing this or something similar.

Thireus commented 2 years ago

macOS 12.0.1 Intel here. Such a weird issue indeed with wss:// completely stuck with "WebSocket is closed before the connection is established". Private Window seems to work just fine. Had that issue with: Version 1.32.81 Chromium: 95.0.4638.54 (Official Build) beta (x86_64) Just upgraded to a new release, the issue seems to be gone (at least for now): Version 1.32.84 Chromium: 95.0.4638.54 (Official Build) beta (x86_64)

we commented almost at the same time...

so for you did it actually happen on Chrome and not on Brave?

For me in 2 years with this issues it never happened in chrome... or rather MAYBE once... in Brave every few weeks, sometimes days, sometimes months.

Same, same... more than 2 years I would say really...

This is Brave Beta version that I use. But indeed it happens every few weeks, sometimes days as you mention. This is driving me crazy, having to manually reload websites that use live streams with websockets every now and then because of that issue.

But today on Brave Beta version 1.32.81 no matter what I tried it would not connect to wss at all (only in Private Window mode). I noticed there was a new Beta version 1.32.84 a few minutes ago, so I upgraded, now wss works, but I bet this is just a rollback to the previous behaviour with wss getting suck every few weeks, sometimes days... we shall see.

Edit: issue is back... oh well :(

davidhq commented 2 years ago

I guess WebSockets are tricky :) even more so underlying implementation of the protocol (it seems)

I'm sure Brave team is very competent and if it wasn't tricky, they would already make it work.

Not sure why they had to add or change anything in chromium implementation then?

A good start would be as @chrismccord recommends to actually know what is the difference between vanilla chromium.

davidhq commented 2 years ago

Maybe everyone is moving to WebTransport which will replace WebSockets soonish!

https://www.w3.org/TR/webtransport/

wanton7 commented 2 years ago

@davidhq from Elixir forum thread there was talk about Brave proxying WebSocket connections. So this could be an issue in their proxy implementation here https://github.com/brave/brave-core/blob/master/browser/net/brave_proxying_web_socket.cc or in code that uses it.

grahac commented 2 years ago

Don't know if this helps or not but I have seen this primarily when a site opens multiple different websockets on multiple tabs. It seems like Brave (on windows primarily) only likes one websocket from each domain?

wanton7 commented 2 years ago

@grahac I think issue #19080 is related to this one. It explains that Brave fails to close WebSocket connections properly and gets into to an invalid state where WebSocket connections don't connect anymore.

megalithic commented 2 years ago

@jonathansampson and @brave-dev team, this would be suuuuuch an important thing to fix, since more and more apps and frameworks are using websockets for data transports from client to server (Phoenix LiveView being the one top of mind).

Any thoughts/updates on this?

tomx-eth commented 2 years ago

My Chrome extension that uses websockets is broken on Brave because of this.

levicki commented 2 years ago

@rebron Since a few updates back web.whatsapp.com stopped working for me -- in network tab I see that it cannot connect to WebSocket. Could that problem be related to this issue or some other?

Note that I have shields disabled and I launch Brave with --disable-brave-extension because I am using uBlock Origin which I also tried disabling, as well as clearing website data for all WhatsApp domains, and it didn't change a thing. Same happens in Incognito Mode, and after browser restart.

EDIT: Added error screenshot:

megalithic commented 2 years ago

@jonathansampson @brave-dev @bbondy friends, how might we assist in addressing these issues? Whatever is causing some of these issues is actually breaking Phoenix LiveView -- a popular web framework for elixir-lang (and many other extensions). I've used all of the Brave release channels (dev/nightly/beta/stable) and no luck (with and without extensions enabled).

chrismccord commented 2 years ago

It is not framework/server specific as several of the examples here have included other platforms.

MoonieKrt commented 2 years ago

@levicki I was struggling with this issue too and was able to workaround it by changing my network type from public to private.

levicki commented 2 years ago

@MoonieKrt

@levicki I was struggling with this issue too and was able to workaround it by changing my network type from public to private.

If that solved it for you then the Windows Firewall was blocking your connections while the network adapter was in public mode.

Inlustra commented 1 year ago

I'm also seeing this exact issue - changing firewalls and network also didn't help. Interestingly enough, changing the website also does not help this one.

I have a Unifi OS Console and a Code-server instance, once Brave gets into this state, neither of those websites will even load.

Incredibly frustrating. I can disable all of my extensions to no avail. The only thing that seems to fix it is a complete closing of all Brave tabs and windows and re-opening

luke3butler commented 1 year ago

Could elevated priority for this issue be considered? I have some clients that use Brave company-wide and are ready to test alternatives because of this issue, so I'm sure there are plenty of others out there that are experiencing it but aren't coming to GitHub to report it.

This could be anecdotal, but it seems like this issue is possibly surfacing whenever Brave has updated but needs to be relaunched.

Is there any data or testing users can provide to help narrow the issue down? It could be that the underlying issue is on the chromium side of things, but it would be nice to figure out the source of the problem.

davidhq commented 1 year ago

This could be anecdotal, but it seems like this issue is possibly surfacing whenever Brave has updated but needs to be relaunched.

Interesting ...

Is there any data or testing users can provide to help narrow the issue down? It could be that the underlying issue is on the chromium side of things, but it would be nice to figure out the source of the problem.

But this never happens in Chrome !

davidhq commented 1 year ago

@BrendanEich .elevatePriority()

@luke3butler wrote ↴

Could elevated priority for this issue be considered? I have some clients that use Brave company-wide and are ready to test alternatives because of this issue, so I'm sure there are plenty of others out there that are experiencing it but aren't coming to GitHub to report it.

luke3butler commented 1 year ago

But this never happens in Chrome !

I didn't find a matching GH issue (didn't look for too long), but did come across this from Pusher. They wrote that a year ago it seems, but wouldn't rule out its relevance entirely.

After I read that, my brain linked it to this issue, which is why I said my evidence could be anecdotal.

davidhq commented 1 year ago

But this never happens in Chrome !

I didn't find a matching GH issue (didn't look for too long), but did come across this from Pusher. They wrote that a year ago it seems, but wouldn't rule out its relevance entirely.

After I read that, my brain linked it to this issue, which is why I said my evidence could be anecdotal.

I would still say there is something radically different between Brave and Chrome in this regard and exactly the same issue does not happen in Chrome. I developed some apps with websockets and always had problems in Brave / never in Chrome or maybe once or twice long time ago.. maybe... but Brave issues continued so I stopped using Brave... now all of this is distant past for me personally.

Hopefully they do resolve this bug one of these years though !

davidhq commented 1 year ago

and it might actually take years :)

bbondy commented 1 year ago

Sorry for the wrong prioritization, we're discussing this internally. I adjusted the priority/p5 label to priority/p3.

Dev-Dipesh commented 1 year ago

Experiencing the same issue with Deepnote on Chrome Version 108.0.5359.124 (Official Build) (x86_64), MacOS 13.1. Only working in incognito since the issue :]

ngocpn57 commented 1 year ago

Same here. It happens more often if I open up DevTools to inspect the websocket connections and then leave it open for a while. Reload the page then every ws connection from the same domain just hangs

Inlustra commented 1 year ago

Not sure if this helps at all, but the same issue does happen in Vivaldi, this became such a pain for me that I migrated over.

However the issue definitely persists over there. I've now moved on to ungoogled-chromium which does not seem to have this issue.

maxorlovsky commented 1 year ago

Seems like this is still not fixed. Any way we can assist and provide info to debug it? Biggest issue I see though is that there is no errors.

megalithic commented 1 year ago

@bbondy or others - for a couple of years now we've had this issue; while we wait for prioritization and hopefully for fixes, is there a workaround (other than using a different browser)? So far the only temporary workarounds I've seen are to relaunch Brave, and sometimes that doesn't do it (takes a couple tries).

lanthias commented 1 year ago

This is blocking me using Brave right now for core applications we use. Works fine in Chromium and Safari.

megalithic commented 1 year ago

Just updating: still very much an issue on dev build of Brave with ws and wss. On MacOS 13.6, M2 Max.

Karunamon commented 1 year ago

I finally figured out that the strange behavior I have been seeing is web socket related, and a look at the console confirms it is this problem, so +1 from me as well. Windows 10 22H2, browser 1.59.117 , though it's been happening for months across multiple versions.

It does not matter whether or not there are updates pending.
I am running a pretty restrictive software firewall (simplewall), but this problem started before I begin using it. Brave is white listed besides, so this is not a firewall problem.
It's also not an environment problem. This happens on popular public websites (the usual indication that I hit this bug is the inability to connect to chat on Twitch) but also on sites in my LAN (I run an instance of uptime kuma, and if web sockets are broken, the application is unusable)
In my case it seems to be time-related. I keep my machine on during the day and in sleep mode at night. It has never happened twice in the same day (after a full browser restart), so there is a minimum time between recurrences of about 12 hours. Sleep mode does not reliably trigger it.

Hope this helps

pejrich commented 7 months ago

Sorry for the wrong prioritization, we're discussing this internally. I adjusted the priority/p5 label to priority/p3.

Hey, curious how much longer that discussion will be going on for? I was gonna grab some lunch, do you think you'll be discussing this for another 18 months or so? Just wanted to get a gauge on time, so I don't accidentally miss some movement on it. Ya'll make the Tar Pitch Drop look like Formula 1. https://en.wikipedia.org/wiki/Pitch_drop_experiment

jokaorgua commented 6 months ago

is there any kind of progress here? I guess in a couple of days we are going to celebrate 3 years of this bug. :)) Really? It seems it is time to move to Google Chrome or Chromium if Brave does want to move on with fixing bugs

bezenson commented 5 months ago

Any chance it's going to be fixed?

I'm developer and my app uses WebSocket. A little bit tired to reload browser during the day to fix the issue. And was really wondered that issue exists for 3 years...

wanton7 commented 5 months ago

@bezenson highly unlikely because the browser has been broken for over three years when it comes to WebSockets. Lot of sites now days rely on WebSockets for their real-time UI updates. I would expect Brave users have experienced all kinds of odd issues in all these years.

You can detect Brave browser with navigator.brave.isBrave(). Just give warning when someone is using Brave and explain that the browser team hasn't fixed this known bad issues in three years and add link to this issue.

pejrich commented 5 months ago

Maybe the 2nd best programmer in the world, according to this list: https://unstop.com/blog/best-programmers-in-the-world could lend us a hand. Because like so many people out there, when I hear the names Ritchie, Knuth, Kernigan, Torvalds, I yawn, and say "you think they're smart?! What about that guy who owns that browser company that can't even do Websockets! He's the 2nd best programmer in the world!" (unless you happen to be someone who uses websockets)