socket.io does not work on Firefox 6 beta

[DanielBaulig]

When using socket.io in Firefox 6 beta the connection will hang after performing authorization. The connect event will not be fired on the server. The Firefox debugging console provides the following information:

Error: Syntax-Error
Sourcefile: http://host/socket.io/1/?t=1310553989400
Line: 1, Column: 1
Sourcecode:
190006406397831442:15:25:websocket,htmlfile,xhr-polling,jsonp-polling

Since firefox claims a syntax error maybe a correct mimetype will help (there's none set in the response)?

[DanielBaulig]

So i changed the Content-Type of the handshake response to 'text/plain; charset=UTF-8' and it fixed the syntax error. The connection will still hang after that though.

[DanielBaulig]

Oh wait, I just realized that the client tries to initialize a WebSocket but that this fails with the following error:

Error: WebSocket is not a constructor
Sourcefile: http://danielbaulig.de:8000/socket.io/socket.io.js
Line: 2197

I read up a bit about Firefox 6 and websockets and found this:

Note: Keep in mind that the WebSocket object is prefixed on Firefox 6.0, and that you need to use MozWebSocket there.

(https://developer.mozilla.org/en/WebSockets/Writing_WebSocket_client_applications)

If I call new WebSocket in the console of Firefox 6 it gives me the above error. If I call new MozWebSocket I get an error about missing parameters, whuch looks promising. However:

WebSockets support in Firefox 6 has been upgraded to a newer version of the protocol compared to the version available in Firefox 4 and 5. Firefox 6 implements what's known as version 07 of the WebSockets RFC (implemented in bug 640003). The new version is backwards incompatible, so it might not work with server implementations based on the old protocol. WebSockets is enabled by default in Firefox 6.

(https://developer.mozilla.org/en/WebSockets)

I do not know if socket.io already supports this new protocol version. Maybe socket.io should fall back to XHR/Flash for Firefox 6 in the meantime?

[DanielBaulig]

I tried some stuff like checking in WS.open if MozWebSocket exists and if so generating that instead of WebSocket, but it seems socket.io does not cope with the new WebSocket protocol (the Socket keeps disconnecting).

The easiest workaround seems to be checking for MozWebSocket before calling io.connect and if it exists simply call io.connect('host', {transports: ['xhr-polling']}); (you can also check for flash and add it if it is available). This way you circumvent the Firefox 6 problem.

[3rd-Eden]

Firefox 6 uses a different WebSocket specification than the 2 that we support. Firefox 6 still in beta so there might still be changes in the code base that affect us.

Also see bug #232

[3rd-Eden]

According to the comments on https://bugzilla.mozilla.org/show_bug.cgi?id=664692 a fix for this should land soon in Aurora. Keeping this open until we can confirm that the bug has been fixed inside firefox.

[starwed]

Firefox 6 is now released, and Bug 664692 mentioned above has been resolved fixed in FF6.

[bigal488]

Have just installed the release version of FF6. Socket.io is now falling back to using XHR. I see the following response in Firebug before XHR is used
GET http:///socket.io/1/?t=1313753717030

Returns:
9159289782059202187:15:25:websocket
But the XML tab of Firebug shows:

XML Parsing Error: syntax error Location: moz-nullprincipal:{412755d3-4777-b341-9828-7a05293049a8} Line Number 1, Column 1:
9159289782059202187:15:25:websocket

What gives? WebSockets were working perfectly for me in FF5. I'm using the latest version of socket.io (0.7.9). Anyone else seeing this?

[Morriz]

I have the same problem. Socket.io resorts to polling.

I noticed that the FF6 final still uses MozWebSocket. Socket.io 0.7.9 is not testing against that. But imo it should, since FF6 is final. When Mozilla decides to implement WebSocket we'll file a bug again ;)

This little mod could work:

in socket.io.js:

this.websocket = 'WebSocket' in window ? new WebSocket(this.prepareUrl() + query)
                                       : new MozWebSocket(this.prepareUrl() + query);

and in websocket.js:

WS.check = function () {
return ('WebSocket' in window && !('__addTask' in WebSocket)) || ('MozWebSocket' in window && !('__addTask' in MozWebSocket));
};

But it doesn't :(

Guess it needs a little extra work...

[steveWang]

You could simply try the following shim (clientside, of course):

if (!window.WebSocket) {
  window.WebSocket = window.MozWebSocket;
}

[Morriz]

That would be even simpler indeed. It just doesn't work. Probably MozWebSocket has a slightly different api.

---

On 24Aug, 2011, at 05:25 , steveWang wrote:

You could simply try the following shim:

if (!window.WebSocket) {
window.WebSocket = window.MozWebSocket;
}

Reply to this email directly or view it on GitHub:
#377 (comment)

[tj]

fireferret

[steveWang]

Morriz: That's because FF6+ uses a different websocket standard, which still isn't supported by Socket.IO.

[sussegaduss]

yeah.. i've tried that but it doesnt work!!!

Sent from my iPhone

On 24/08/2011, at 00:27, Morriz
reply@reply.github.com
wrote:

That would be even simpler indeed. It just doesn't work. Probably MozWebSocket has a slightly different api.

---

On 24Aug, 2011, at 05:25 , steveWang wrote:

You could simply try the following shim:

if (!window.WebSocket) {
window.WebSocket = window.MozWebSocket;
}

Reply to this email directly or view it on GitHub:
#377 (comment)

Reply to this email directly or view it on GitHub:
#377 (comment)

[tj]

did you try fireferret

[Charuru]

It's not going to work, it's a different spec.

[3rd-Eden]

Should be fixed in 0.8

[bigal488]

No difference for me using Socket.io 0.8.2 and FF 6.0.1 on Mac OS X???

[einaros]

@bigal488, I'm also using FF 6.0.1 on OS X and that works quite well. Did you see any error messages in the server logs, or network / console in FireBug?

[pyrostrex]

@einaros, same as @bigal488, I got the same problem.

Here are my info's :

Node v0.4.11
Socket.IO v0.8.2
Express v2.4.6
Server run on VPS and Client run on my Mac OS X
Client can went up to 130kbps connection speed
Server is in US and Client is in Malaysia
Socket.IO configured to only accept WebSocket

Server log :

debug - client authorized
info  - handshake authorized 1871387161602381203

Client log :

[20:22:33.166] GET http://server_ip/socket.io/1/?t=1314793352912 [HTTP/1.1 200 OK 531ms]
[20:22:33.664] syntax error @ http://server_ip/socket.io/1/?t=1314793352912:1

Hope i didn't miss anything.

[einaros]

@pyrostrex, can you see which source line it complains about?

Alternatively, could you see if my socket.io-client fork fixes the issue? https://github.com/einaros/socket.io-client

[bigal488]

I see exactly the same errors as @pyrostrex

Error: syntax error
Source File: http://192.168.0.112/socket.io/1/?t=1314794076332
Line: 1, Column: 1
Source Code:
19819915361867072489:15:25:websocket

and Firebug reports:

XML Parsing Error: syntax error Location: moz-nullprincipal:{1997ebe5-7577-0843-9de1-ff5ed539b485} Line Number 1, Column 1:
878017279361805341:15:25:websocket

The response headers show only:

Connection  keep-alive
Transfer-Encoding   chunked

[einaros]

@bigal488, @pyrostrex, Alright, thanks. I pushed an update to https://github.com/einaros/socket.io. See if that fixes the issue.

[pyrostrex]

@einaros, that's the problem, the console only complains about the syntax error that was returned by the latest http request but then it's like it doesn't do anything at all after the syntax error. It complains on line 1. everytime will be on line 1. But when i stopped using websocket (enables everything other than websocket). the syntax error is not a problem at all. It just skip through the syntax error and move on to the other request.

For chrome, I'm using the latest and of course, Mac OS X Chrome doesn't have any problem. But when I used Windows 7's Chrome, this is where the nightmare comes. The problem lies when the client send the upgrade websocket request. It just hangs. It's like the request was made right before socket.io can finish its interception with the express route "/1/websocket/....". Then, the second problem is, when I enabled all transports including websocket, it will not revert to any other transports after trying to connect to WebSocket transport.

Edit: I tried ur fork, the problem is still exist.

[einaros]

@pyrostrex,

Edit: I tried ur fork, the problem is still exist.

Does this refer to my fork of socket.io-client, or my last post pointing to my socket.io fork? I'd be surprised if the latter doesn't fix this.

[pyrostrex]

@einaros, oh no no. That refers to the client.. I was going to post before u send the new update push. And...... Thanks for the update, now it works! lol. Going to try the chrome now.

Edit : @einaros, Google Chrome on Windows 7 problem still exist.

[bigal488]

Yes - the combination of your socket.io and socket.io-cleint is working for me too - thanks very much.
Was it the lack of a content-type header on the handshake responses that was the main problem?

[commadelimited]

I'm experiencing this issue as well. It also seems to fail in Chrome 15b as well.

Sounds like bigal488 got it working but I'm not sure of the steps he/she took to accomplish it.

Anyone have a quick writeup on what to do? I'm hosting my Node service at http://no.de if it makes a difference.