Closed Bug 1467107 Opened 6 years ago Closed 6 years ago

WebSocket.close throws InvalidAccessError


(Core :: DOM: Networking, defect)

60 Branch
Not set



Tracking Status
firefox60 --- affected


(Reporter: bugzilla, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180516032328

Steps to reproduce:

Calling the WebSocket.close method in a WebSocket message event handler throws the error InvalidAccessError no matter what I pass it. The docs [1] say this error occurs when an invalid code was passed. But I tried with different codes from the list of supported codes. So something isn't working as advertised here. I cannot close the connection as a reaction on the wrong message received.

Closing the connection from other contexts works though. Interestingly, putting the close call in a setTimeout doesn't help either. It just lets the script fail later.

This is a part of the full code:

function MyClient() {
	"use strict";
	var webSocket;
	this.connect = function (uri) {
		webSocket = new WebSocket(uri);
		webSocket.binaryType = "arraybuffer";
		webSocket.addEventListener("message", onMessage.bind(this));
	this.close = function () {
	function onMessage(event) {
		if (!isHandshakeComplete) {
			var banner =;
			if (banner !== "Sample") {
				let errorMessage = "Unexpected handshake banner";
				webSocket.close(1002 /* protocol error */, errorMessage);
			isHandshakeComplete = true;
		// ...

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 (20180611100116)

Based on other similar reports I think the correct component would be Core::Networking:WebSockets. Please change if this is not the right component.
Component: Untriaged → Networking: WebSockets
Product: Firefox → Core
My reading of the
is that applications may pass a number between 3000-4999 (more specifically libraries should use the 3000 range, and applications the 4000 range) or 1000 in case of no errors. The other error codes are used by the browser - for example 1015 will be used when there's a failed TLS handshake. If you were able to use it, it could send a wrong signal that the TLS handshake failed.

The code we have reflects that.

Please reopen if you think this is wrong.
Closed: 6 years ago
Component: Networking: WebSockets → DOM: Web Sockets
Flags: needinfo?(nospam)
Resolution: --- → INVALID
I wouldn't read the MDN page like that but the code is clear about it. So this is probably a documentation issue instead of a code one. It should be clarified that the 1xxx codes are only WebSocket-internal and not for the same meaning by the transported data (like when the application-layer protocol is invalid).
Flags: needinfo?(nospam)
Thanks for updating the MDN page. Cheers!
You need to log in before you can comment on or make changes to this bug.