When a WebSocket connection is active and users refreshes the page an error is logged: "The connection to ... was interrupted while the page was loading"
Categories
(Core :: Networking: WebSockets, defect)
Tracking
()
People
(Reporter: phil, Assigned: baku)
References
Details
(Keywords: DevAdvocacy, Whiteboard: [necko-backlog])
Attachments
(2 files)
41.09 KB,
image/png
|
Details | |
678 bytes,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 Steps to reproduce: Here's an example in action: 1. Go to http://www.leggetter.co.uk/pusher/bugs/ws_interrupted/ 2. Open up the JavaScript console/Firebug 3. "open" should be logged in the console. If it's not refresh the page so that you see that log message. 4. Refresh the page and you'll see an error being logged that states: "The connection to <WebSocket Server> was interrupted while the page was loading" Actual results: An unexpected error was logged. There's no way of stopping the error being logged and it appears to be related to the existing WebSocket/MozWebSocket instance since the error message links to the point where the new WebSocket object was originally created. I've replicated this in FF8 but I've reports of the same issue being seen in older versions of Firefox. Expected results: No error should be logged or there should be some way of catching and stopping the error.
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Comment 1•11 years ago
|
||
Confirming, I see this all the time with websockets.
Not only that, but the error appears AFTER an unrelated page has loaded! Repro: 1. Load a page like http://superuser.com/questions/223396/mbr-boot-sector-wiping-virus-trojan/307673?noredirect=1#comment853472_307673 2. Load something else in the same tab, eg http://gmail.com 3. Watch net and JS activity in the script console. 15:23:42.826 The connection to ws://sockets.ny.stackexchange.com/ was interrupted while the page was loading. full.en.js:15 15:23:43.081 GET http://mail.google.com/mail/ [HTTP/1.1 302 Moved Temporarily 37ms] 15:23:43.082 GET https://accounts.google.com/ServiceLogin [HTTP/1.1 200 OK 31ms] 15:23:43.730 GET https://accounts.youtube.com/accounts/CheckConnection [HTTP/1.1 200 OK 16ms] 15:23:43.843 GET https://mail.google.com/mail [HTTP/1.1 204 No Content 138ms] 15:23:43.844 GET https://mail.google.com/mail/images/c.gif [HTTP/1.1 200 OK 138ms] 15:24:02.826 The connection to ws://sockets.ny.stackexchange.com/ was interrupted while the page was loading. full.en.js:15 15:24:05.812 GET https://mail.google.com/mail [HTTP/1.1 204 No Content 139ms]
I confirm the bug. Is there any workaround so the message won't get display on refresh?
Comment 4•10 years ago
|
||
Also - https://bugzilla.mozilla.org/show_bug.cgi?id=1055240 The WebSocket shouldn't be closed on submit.
Comment 5•10 years ago
|
||
So is this bug fixed or going to be fixed? It's inconsistent with other browsers and the websocket spec. It is a problem because it closes the websocket after the page loads for no reason, which breaks server side websocket code.
Comment 8•9 years ago
|
||
I've got the same problem, do you have any solution?
Comment 9•9 years ago
|
||
Still happening in 37
Comment 10•9 years ago
|
||
Still happening in 38.0.5
Comment 11•9 years ago
|
||
Still happening in Firefox Developer Edition 40.0a2
Comment 12•9 years ago
|
||
This can be fixed on the client side by checking on window load if the socket is open or not: $(window).on('beforeunload', function(){ socket.close(); }); See discussion here: http://stackoverflow.com/questions/14140414/websocket-interrupted-while-page-is-loading-on-firefox-for-socket-io Probbably still a bug, but it's a workaround at least.
Comment 13•9 years ago
|
||
The error message in the unloading page is no problem for me. Here it is with the exchange of messages after acceptance of connection. It started happening from version 37 of Firefox. With IE and Chrome this problem does not happen.
Comment 14•9 years ago
|
||
Still happening in ver 41.0 Message:The connection to ws://.....? was interrupted while the page was loading.Please note, we are using MS SignalR in our application.
Comment 15•9 years ago
|
||
Just wanted to subscribe to see the progress.
Comment 16•9 years ago
|
||
I think this may be rendering an application working in Chrome entirely unusable in Firefox.
Comment 17•8 years ago
|
||
Does this error cause a page refresh for anyone else? Is this going to be fixed? Or does anyone have a working example with the "workaround"?
Comment 18•8 years ago
|
||
+ The problem appears sometimes instantly when the page loads. And after that WebSocket calls .onopen
Comment 19•8 years ago
|
||
Sometimes it catchable with .onerror and sometimes not. FF 43.0.4
Comment 20•8 years ago
|
||
Still happening in 43.0.4 (ubuntu)
Updated•8 years ago
|
Updated•8 years ago
|
Comment 21•8 years ago
|
||
This is a huge blocker for a lot of developers as it blocks tools like Browsersync and Livestyle, which are essential if you're doing UI engineering/prototyping. I have an example repo with the code I used to reproduce at https://github.com/helenvholmes/websocket-error-example. Steps to reproduce: 1. Create new local folder with an index.html 2. npm install -g browser-sync 3. browser-sync start --server 4. Make a change in the css (e.g., change the body background color from blue to tomato). Expected Results: The background-color of body changes without reloading the page. Actual Results: Nothing happens. On refresh, the color changes, with the following error in the console: "The connection to ws://localhost:3000/browser-sync/socket.io/?EIO=3&transport=websocket&sid=udKgHT2NeO5ERnOBAAAA was interrupted while the page was loading. http://localhost:3000/browser-sync/browser-sync-client.2.11.1.js:3:5109"
Comment 23•8 years ago
|
||
Confirmed STR from Comment 21 with browser sync not working using these steps: 1) git clone https://github.com/helenvholmes/websocket-error-example.git; cd websocket-error-example 2) node ./node_modules/browser-sync/bin/browser-sync.js start --server 3) Make a change in the css (e.g., change the body background color from blue to tomato). I do see the "The connection to ws://......" error but only after reloading - I do see this error repeating in the browser console while the tab is opened. GET XHR http://localhost:3000/sockjs-node/info [HTTP/1.1 404 Not Found 1ms] [WDS] Disconnected! bundle.js:643:4 newConnection/sock.onclose() bundle.js:643 EventTarget.prototype.dispatchEvent() bundle.js:3582 SockJS.prototype._close/<() bundle.js:6732 (Async: setTimeout handler) SockJS.prototype._close() bundle.js:6720 SockJS.prototype._receiveInfo() bundle.js:6554 g() bundle.js:3506 EventEmitter.prototype.emit() bundle.js:3520 InfoReceiver.prototype.doXhr/<() bundle.js:7529 g() bundle.js:3506 EventEmitter.prototype.emit() bundle.js:3520 InfoAjax/<() bundle.js:7740 g() bundle.js:3506 EventEmitter.prototype.emit() bundle.js:3520 AbstractXHRObject.prototype._start/this.xhr.onreadystatechange() bundle.js:4139 (Async: EventHandlerNonNull) AbstractXHRObject.prototype._start() bundle.js:4100 AbstractXHRObject/<() bundle.js:4040 (Async: setTimeout handler) AbstractXHRObject() bundle.js:4039 XHRLocalObject() bundle.js:4219 InfoAjax() bundle.js:7722 InfoReceiver._getReceiver() bundle.js:7498 InfoReceiver.prototype.doXhr() bundle.js:7518 InfoReceiver/<() bundle.js:7487 (Async: setTimeout handler) InfoReceiver() bundle.js:7486 SockJS() bundle.js:6498 newConnection() bundle.js:634 newConnection/sock.onclose/<() bundle.js:648 (Async: setTimeout handler) newConnection/sock.onclose() bundle.js:647 EventTarget.prototype.dispatchEvent() bundle.js:3582 SockJS.prototype._close/<() bundle.js:6732 (Async: setTimeout handler) SockJS.prototype._close() bundle.js:6720 SockJS.prototype._receiveInfo() bundle.js:6554 g() bundle.js:3506 EventEmitter.prototype.emit() bundle.js:3520 InfoReceiver.prototype.doXhr/<() bundle.js:7529 g() bundle.js:3506 EventEmitter.prototype.emit() bundle.js:3520 InfoAjax/<() bundle.js:7740 g() bundle.js:3506 EventEmitter.prototype.emit() bundle.js:3520 AbstractXHRObject.prototype._start/this.xhr.onreadystatechange() bundle.js:4139 (Async: EventHandlerNonNull) AbstractXHRObject.prototype._start() bundle.js:4100 AbstractXHRObject/<() bundle.js:4040 (Async: setTimeout handler) AbstractXHRObject() bundle.js:4039 XHRLocalObject() bundle.js:4219 InfoAjax() bundle.js:7722 InfoReceiver._getReceiver() bundle.js:7498 InfoReceiver.prototype.doXhr() bundle.js:7518 InfoReceiver/<() bundle.js:7487 (Async: setTimeout handler) InfoReceiver() bundle.js:7486 SockJS() bundle.js:6498 I don't know if 'browser sync not working' is directly related to the connection interrupted error or a different bug
Updated•8 years ago
|
Comment 24•8 years ago
|
||
So, I tested this with both Firefox Nightly and Chrome on Linux. I think this isn't a websocket issue, but a problem with browser-sync. The websocket is connected, but no messages are being sent by browser-sync. I see the exact same behaviour in Chrome. This is most likely not a bug in our browser, and definitely not related to the name of this bug - the error message being shown in the console.
Comment 25•8 years ago
|
||
(In reply to Valentin Gosu [:valentin] from comment #24) > So, I tested this with both Firefox Nightly and Chrome on Linux. > I think this isn't a websocket issue, but a problem with browser-sync. The > websocket is connected, but no messages are being sent by browser-sync. I > see the exact same behaviour in Chrome. > > This is most likely not a bug in our browser, and definitely not related to > the name of this bug - the error message being shown in the console. Can we possibly reach out to the Browsersync and Livestyle projects then to help them out? A bunch of people are not using Firefox because of this (albeit symptomatic) bug.
Updated•8 years ago
|
Comment 26•8 years ago
|
||
The workaround is to recover connection using .onclose and .onerror
Comment 27•8 years ago
|
||
Sara Soueidan just tweeted about how Browsersync is rad and feels relevant to the current thread since it can't be used with Firefox: https://twitter.com/sarasoueidan/status/712264402335100928
When I follow the steps from :helenvholmes in comment 21 and then save some CSS change, neither Firefox nor Chrome updates. If I add "--files ." to the Browsersync command, it prints a new line "Watching files..." and syncs on save in both Firefox and Chrome. Is there something else needed to reproduce the issue you are seeing?
Comment 29•8 years ago
|
||
I'm getting the same functionality as Ryan on both my test page and some other projects I have locally that use Browsersync. I guess something has changed on those projects since I started noticing this error? The bug I'm sure if still valid, just not relevant to Browsersync anymore. We should probably check that this isn't affecting Livestyle.
Comment 30•8 years ago
|
||
OK based on the last few comments it seems like this is not related to the live reload tools. What I'm not sure about is if there's a scenario where this message is providing value to devs. Like, is there some action people should take to get the message to go away on their sites? If so, the message should be more specific, maybe pointing to an MDN page with instructions on how to fix it. If not, it should likely be removed. Valentin, what do you think? I guess it's this one: https://dxr.mozilla.org/mozilla-central/source/dom/base/WebSocket.cpp#546
Comment 31•8 years ago
|
||
ni? for opinions on Comment 30. And also +baku who last touched the error message
Comment 32•8 years ago
|
||
Yeah, it's not clear if the message is more of a "best practice" thing or there's an actual error. Based on Stack Overflow, etc., people seem to think that Firefox + websockets is broken on page refresh.
Comment 33•8 years ago
|
||
One weird thing is that the message shows up after the refresh, as if it's happened on the new page. But AIUI the error is happening sometime during unload (which implies the message should be gone on the new page). So maybe there's something going wrong with the console service event when something gets logged on unload.
Assignee | ||
Comment 34•8 years ago
|
||
There are not reasons to have that warning there. The workflow is: nsLoadGroup::Cancel mozilla::dom::WebSocketImpl::Cancel mozilla::dom::WebSocketImpl::CancelInternal And at this point we should just close the webSocket and try to dispatch the 'close' event.
Updated•8 years ago
|
Comment 36•8 years ago
|
||
Thanks for taking this!
Comment 37•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/77b2b963de2c
Comment 38•8 years ago
|
||
This happens even without using SocketIO. I am using Aerys (PHP WebSockets Server). Everything works fine in Chrome, but not in Firefox 47. Getting the same "Conection to ... was interrupted while the page was loading"
Comment 39•8 years ago
|
||
victorbarbu08, this is fixed in 48 (see Comment #37). Please test in Beta or Firefox Devtools to confirm.
Comment 40•7 years ago
|
||
I am still seeing this on Firefox 50.1.0 using signalR
Comment 41•7 years ago
|
||
This issue exists even with Firefox 55.0.3. Particularly I am seeing it with SockJS. Are there any known workarounds since nobody has commented on the thread for 9 months now.
Comment 42•7 years ago
|
||
(In reply to kiran.kashalkar from comment #41) > This issue exists even with Firefox 55.0.3. > Particularly I am seeing it with SockJS. > > Are there any known workarounds since nobody has commented on the thread for > 9 months now. According to Comment #37, this was fixed back in Firefox 48. If you're still seeing the error, it's probably a good idea to file a new bug and link it here in a comment. Ideally you could link to a publicly available server so we can investigate. Thanks!
Comment 43•6 years ago
|
||
Also seeing this in Firefox Quantum 58.0 on macOS 10.12.6, using SocketIO (2.0.4): ``` The connection to http://localhost:4000/__webpack_hmr was interrupted while the page was loading. ``` Was there ever a new issue created to track these last reports?
Comment 44•6 years ago
|
||
In my case I was implementing the websocket server. When the message from server to client is masked (chromium browsers do not allow that) firefox accepts and does not generate the error message and/or close the connection. For the server to client message to be masked the most significant bit of the byte at offset 1 must be set and just after the length(s) byte(s) there must be the four bytes key (just laid out four zeroes and everything goes fine). The workaround then is to detect when the client is firefox (has " Gecko/" or " Firefox/" in HTTP User-Agent header) and then adding the mask and key for the replies only when this was true. The server was base on code in https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_a_WebSocket_server_in_Java.
Comment 45•6 years ago
|
||
Today I performed more tests and couldn't reproduce the problem. Think there was a flaw in the websocket server implementation which caused the problem (FIN combined with continuation frame and text frame). Worked fine even sending the server to client frame without masking and without the four bytes key. Tested with Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0.
Comment 46•5 years ago
|
||
I'm seeing this again in Firefox 67.0
Comment 47•5 years ago
|
||
Yes, this bug is again exist.
Updated•5 years ago
|
Comment 48•5 years ago
|
||
I have this problem in both 68.0b13 (64-bit) and 69.0a1
Updated•5 years ago
|
Comment 49•5 years ago
|
||
I also have this, in 68 just after upgrading, this is crazy how can such a huge issue find its way into production? basically renders entire app useless. Also 15+ days and sill no solution is this not a major issue. Going to have start dev ing on chrome... :(
Comment 50•5 years ago
|
||
Does anyone have a public URL we can test against?
Comment 51•5 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #50)
Does anyone have a public URL we can test against?
Someone put this up for https://bugzilla.mozilla.org/show_bug.cgi?id=858538#c21 which is a linked issue.
Comment 52•5 years ago
|
||
Thanks Cody, that's helpful. Are you able to reproduce the error on that page? If so, what are the steps to reproduce? (i poked around, but didn't see the issue as reported on 69 on macOS).
Updated•5 years ago
|
Comment 53•5 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #52)
Thanks Cody, that's helpful. Are you able to reproduce the error on that page? If so, what are the steps to reproduce? (i poked around, but didn't see the issue as reported on 69 on macOS).
On 68 on macOS if I click connect it starts streaming "Hello, Anthony!" if I then click download file the streaming stops. On any other browser (Chrome, Edge, Safari) it will continue to stream "Hello, Anthony!" after download is clicked.
Comment 54•5 years ago
|
||
Thanks, ni? myself to file a new bug for investigation.
Comment 55•5 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #54)
Thanks, ni? myself to file a new bug for investigation.
Also I just verified is still is a bug in 70.0a1 (2019-07-12)
Updated•5 years ago
|
Comment 56•5 years ago
|
||
Mike (In reply to Mike Taylor [:miketaylr] from comment #54)
Thanks, ni? myself to file a new bug for investigation.
Also I think the active open bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=896666
Updated•5 years ago
|
Description
•