brave-browser
brave-browser copied to clipboard
brave
WebSocket sometimes fails to reconnect until browser restart or website access from incognito mode
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:
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
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!
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.
?
@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.
@rebron no, the issue is not in that list and the problem does not happen in Chrome, it's a Brave issue
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", ...)
@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!
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.
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
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.
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 :(
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.
Maybe everyone is moving to WebTransport which will replace WebSockets soonish!
https://www.w3.org/TR/webtransport/
@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.
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?
@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.
@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?
My Chrome extension that uses websockets is broken on Brave because of this.
@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:
@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).
It is not framework/server specific as several of the examples here have included other platforms.
@levicki I was struggling with this issue too and was able to workaround it by changing my network type from public to private.
@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.
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
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.
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 !
@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.