1204727 - Open websocket throws NS_ERROR_NOT_CONNECTED in .send call

Status: UNCONFIRMED

(Core :: Networking: WebSockets, defect, P3)

Description

[Andrew Morris]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150617030205

Steps to reproduce:

Call .send on an open websocket (reproducible as part of a larger test but not seeing this elsewhere).

```
if (webSocket.readyState === webSocket.OPEN) {
  try {
    webSocket.send(msg);
  } catch(err) {
    debugger; // This gets hit
    console.error(err);
    throw err;
  }
}
```


Actual results:

Threw exception NS_ERROR_NOT_CONNECTED


Expected results:

Exception should not have been thrown, since the websocket is in the open state.

I'm unclear on whether this should be possible. It seems to be the same issue seen by the reporter of https://bugzilla.mozilla.org/show_bug.cgi?id=977020 but that bug was resolved claiming https://bugzilla.mozilla.org/show_bug.cgi?id=960508 was the only real issue, that apparently a change was needed to the thrown error object. What I'd like to know is whether this is really intended behaviour and what would cause this exception to be thrown on a websocket which claims to be open.

I'm seeing this on 40.0.3 but not my nightly instance which is 41.0a1 (2015-06-17).

Comment 1

[Loic]

Could you attach a minimal testcase, please.

Comment 2

[Andrew Morris]

Sorry for the slow response. I wish I could attach a minimal test case for you, but I do not yet know what is required to reproduce this issue and what is not. Is there any situation that is suspected to sometimes cause this error? And that therefore robust code should handle it? Or is it definitely a bug that shouldn't happen, assuming the webSocket in the code I provided is a real untampered WebSocket?

Since I am able to reproduce this issue in my environment (at least I hope that's still the case), is there any way I can pull information out of the dev tools for you that would be relevant?

Comment 3

[Loic]

Is it possible to reproduce the issue in a jsfiddle or something like that? Or do you have a live testcase?

Comment 4

[Andrew Morris]

Hi Loic. Sorry for the slow response. I've prepared a jsbin for you. It requires two clients to work, one with #moderator on the url:

http://output.jsbin.com/gogiviwive#moderator
This one can just be started once and left running indefinitely.

http://output.jsbin.com/gogiviwive
This one shows the issue and can be refreshed as many times as needed to keep hitting it. Sometimes the error doesn't show but I see it about 70% of the time.

PS: Now on FF 44.0, looks like everything is the same regarding this issue.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258