search

Flotype / now

NowJS makes it easy to build real-time web apps using JavaScript
http://www.nowjs.com
MIT License
1.91k stars 175 forks source link

`Now` Fails to Work in Firefox #121

Closed 7fe closed 13 years ago

7fe commented 13 years ago

The multiroomchat_examples in examples fails to work for firefox 3.6.6 on Ubuntu. I'm not certain if its a socket.io or a now issue, but the users name comes across as undefined.

ruiiiijiiiiang commented 13 years ago

Hi limeblack, are you using now 0.6 or 0.7? Can you please post the errors you're getting? Thank you.

7fe commented 13 years ago

I'm on .6, I'll try updating.

7fe commented 13 years ago

No luck on .7. Everything works fine in Chrome just Firefox 3.6 is giving issues.

I'm not getting any errors, just the firefox input isn't coming through.

 13 Jul 18:55:54 - Your node instance does not have root privileges. This means that the flash XML policy file will be served inline instead of on port 843. This will slow down initial connections slightly.
13 Jul 18:55:54 - socket.io ready - accepting connections
13 Jul 18:56:33 - Initializing client with transport "xhr-multipart"
13 Jul 18:56:33 - Client 7998917982913554 connected
Joined: undefined

I also tried the testing using sudo, but no luck then either.

ruiiiijiiiiang commented 13 years ago

You're right. I'm getting the same result testing with firefox 5. I'll look into it.

steveWang commented 13 years ago

What do you mean by "fails to work"? The user's name is coming up as undefined because the multiroom chat is listening for the wrong event (should be everyone.on('join', cb) instead of nowjs.on('connect', cb)), but other than that, it works just fine. My guess as to why Chrome works is because Chrome can actually connect via websockets (it's disabled by default in FF for versions less than 6), so Chrome's connection is way faster / better.

Also, there's no need to use sudo unless you're attaching the node server to port 80.

7fe commented 13 years ago

@steveWang According to the console sudo increases connectivity for the flash xml policy.

Your node instance does not have root privileges. This means that the flash XML policy file will be served inline instead of on port 843. This will slow down initial connections slightly.

Anyways about the issue, Firefox does nothing, well nothing useful. It successfully receives and sends messages but all data comes across as `undefined'.

The same issue is supposedly occurring in Firefox 3.6 - 5. node server.js and take a look.

steveWang commented 13 years ago

I ran multiroomchat_server.js in FF5 under both Now 0.6.1 and Now 0.7.0 without any issues, so I don't understand what you mean.

7fe commented 13 years ago

Which OS? Also, did you try sending messages with a Chrome/Opera.. window also open? Just making sure. @curraheerecursed suggested he had the same results in F5, I'm testing in F3.6

steveWang commented 13 years ago

OpenSUSE 11.4. And yes, I sent messages with Chrome 14 on the side. Bidirectional communication was working (i.e. Chrome could talk to FF and vice versa).

steveWang commented 13 years ago

Hmm. With FF3.6, looks like the client can't establish a connection for some reason under Now 0.7 (looks like flashsocket and XHR-multipart are both failing, and the server doesn't ever notice a client attempting to connect). Under Now 0.6, the name comes up as null unless firebug console is open. I'm really not sure what to make of this.

steveWang commented 13 years ago

And now I don't get the bug any more now that I'm not messing around with my build environment. Still using FF3.6.19 and Chrome 14.0.814.0.

I still do get that the user's name is null with Now 0.6, but that's a deficiency with Now 0.6, since we use prompt() in the example.

ericz commented 13 years ago

@limeblack @steveWang

In the multichatroom example names are created using prompt(..).

In Firefox, and also other browsers, whether prompt blocks the entire Javascript execution thread is not always known. Whether things like Firebug or other debug consoles are open change the behavior of that.

If the prompt is not blocking, then code will continue to execute and the username will be sync as undefined, however if it is blocking, the code will not continue until the name is set and thus the proper name is synced.

This is not a bug but rather an issue with the unpredictability with how prompt behaves.

The ideal solution would be to not use prompt in the code. It is a quick hack for the examples and I don't think anyone will try to actually use it in production.

@limeblack, if you need anymore help with this issue feel free to message me directly.