712329 - 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"

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Phil Leggetter]

Attachment: Firefox WebSocket connection interrupted error log in console.

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.

Comment 1

[Mark Banner (:standard8)]

Confirming, I see this all the time with websockets.

Comment 2

[Cees T.]

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]

Comment 3

[daniphp]

I confirm the bug. Is there any workaround so the message won't get display on refresh?

Comment 4

[Cody Lerum]

Also  - https://bugzilla.mozilla.org/show_bug.cgi?id=1055240

The WebSocket shouldn't be closed on submit.

Comment 5

[Darren Govoni]

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 6

[lxsameer]

I have the same bug on firefox developer edition 35.a

Comment 7

[almstrand]

Still happening in FF 36.0.4.

Comment 8

[cieslinska.dorota]

I've got the same problem, do you have any solution?

Comment 9

[Andrew Cook]

Still happening in 37

Comment 10

[tzaitsev]

Still happening in 38.0.5

Comment 11

[Fábio Melo]

Still happening in Firefox Developer Edition 40.0a2

Comment 12

[Kevin Cannon]

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

[Fábio Melo]

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

[prabhu_sm]

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

[igor.timoshenkov]

Just wanted to subscribe to see the progress.

Comment 16

[metasoarous]

I think this may be rendering an application working in Chrome entirely unusable in Firefox.

Comment 17

[ethan.w.thornburg]

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

[ScorpioT1000]

+ 
The problem appears sometimes instantly when the page loads. And after that WebSocket calls .onopen

Comment 19

[ScorpioT1000]

Sometimes it catchable with .onerror and sometimes not.
FF 43.0.4

Comment 20

[talgautb]

Still happening in 43.0.4 (ubuntu)

Comment 21

[Helen V. Holmes (:helenvholmes) (:✨)]

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 22

[Valentin Gosu [:valentin] (he/him)]

Taking a look at this.

Comment 23

[Brian Grinstead [:bgrins]]

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

Comment 24

[Valentin Gosu [:valentin] (he/him)]

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

[Helen V. Holmes (:helenvholmes) (:✨)]

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

Comment 26

[ScorpioT1000]

The workaround is to recover connection using .onclose and .onerror

Comment 27

[Helen V. Holmes (:helenvholmes) (:✨)]

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

Comment 28

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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

[Helen V. Holmes (:helenvholmes) (:✨)]

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

[Brian Grinstead [:bgrins]]

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

[Brian Grinstead [:bgrins]]

ni? for opinions on Comment 30.  And also +baku who last touched the error message

Comment 32

[Mike Taylor [:miketaylr]]

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

[Brian Grinstead [:bgrins]]

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.

Comment 34

[Andrea Marchesini [:baku]]

Attachment: ws.patch

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.

Comment 35

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/77b2b963de2c

Comment 36

[Brian Grinstead [:bgrins]]

Thanks for taking this!

Comment 37

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/77b2b963de2c

Comment 38

[victorbarbu08]

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

[Mike Taylor [:miketaylr]]

victorbarbu08, this is fixed in 48 (see Comment #37). 

Please test in Beta or Firefox Devtools to confirm.

Comment 40

[aw.busbin]

I am still seeing this on Firefox 50.1.0 using signalR

Comment 41

[kiran.kashalkar]

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

[Mike Taylor [:miketaylr]]

(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

[write]

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

[edudfla]

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

[edudfla]

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

[chibimagic]

I'm seeing this again in Firefox 67.0

Comment 47

[bars232]

Yes, this bug is again exist.

Comment 48

[mail]

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

Comment 49

[wpitallo]

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

[Mike Taylor [:miketaylr]]

Does anyone have a public URL we can test against?

Comment 51

[Cody Lerum]

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

Comment 52

[Mike Taylor [:miketaylr]]

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

Comment 53

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

Comment 54

[Mike Taylor [:miketaylr]]

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

Comment 55

[Cody Lerum]

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

Comment 56

[Cody Lerum]

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

Comment 57

[Mike Taylor [:miketaylr]]

Cool, thanks.