Closed Bug 712329 Opened 8 years ago Closed 4 years ago

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)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- fixed

People

(Reporter: phil, Assigned: baku)

References

Details

(Keywords: DevAdvocacy, Whiteboard: [necko-backlog])

Attachments

(2 files)

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.
QA Contact: general → networking.websockets
Component: General → Networking: WebSockets
Product: Firefox → Core
OS: Mac OS X → All
Hardware: x86 → All
Version: 8 Branch → Trunk
Confirming, I see this all the time with websockets.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Also  - https://bugzilla.mozilla.org/show_bug.cgi?id=1055240

The WebSocket shouldn't be closed on submit.
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.
I have the same bug on firefox developer edition 35.a
Still happening in FF 36.0.4.
I've got the same problem, do you have any solution?
Still happening in 37
Still happening in 38.0.5
Still happening in Firefox Developer Edition 40.0a2
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.
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.
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.
Just wanted to subscribe to see the progress.
I think this may be rendering an application working in Chrome entirely unusable in Firefox.
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"?
+ 
The problem appears sometimes instantly when the page loads. And after that WebSocket calls .onopen
Sometimes it catchable with .onerror and sometimes not.
FF 43.0.4
Still happening in 43.0.4 (ubuntu)
Whiteboard: [necko-backlog]
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"
Taking a look at this.
Assignee: nobody → valentin.gosu
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
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.
Assignee: valentin.gosu → nobody
(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.
Flags: needinfo?(valentin.gosu)
The workaround is to recover connection using .onclose and .onerror
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?
Flags: needinfo?(hholmes)
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.
Flags: needinfo?(hholmes)
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
Flags: needinfo?(valentin.gosu)
ni? for opinions on Comment 30.  And also +baku who last touched the error message
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(amarchesini)
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.
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.
Attached patch ws.patchSplinter Review
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.
Flags: needinfo?(valentin.gosu)
Flags: needinfo?(amarchesini)
Attachment #8735880 - Flags: review?(bugs)
Attachment #8735880 - Flags: review?(bugs) → review+
Thanks for taking this!
Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/77b2b963de2c
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
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"
victorbarbu08, this is fixed in 48 (see Comment #37). 

Please test in Beta or Firefox Devtools to confirm.
I am still seeing this on Firefox 50.1.0 using signalR
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.
(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!
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?
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.
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.

I'm seeing this again in Firefox 67.0

Yes, this bug is again exist.

I have this problem in both 68.0b13 (64-bit) and 69.0a1

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... :(

Does anyone have a public URL we can test against?

(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.

http://peaceful-sierra-45424.herokuapp.com/

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).

Flags: needinfo?(cody.lerum)

(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.

Flags: needinfo?(cody.lerum)

Thanks, ni? myself to file a new bug for investigation.

Flags: needinfo?(miket)

(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)

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

Cool, thanks.

Flags: needinfo?(miket)
See Also: → 896666
You need to log in before you can comment on or make changes to this bug.