Using the example chat application here, I've written a simple Socket.IO application served over Node.Js which polls a JSON file using a fileRead from the server side and broadcasts the parsed JSON values over to the client side, where I've displaying them.
This works really well in Chrome, Safari and Opera (all those who support WebSockets).
However in Firefox, it fails until I start the Firebug console. That's when the handshake happens and the data is displayed.
In IE, it just doesn't work.
When I deploy the same code with SSL, it works everywhere. Any ideas on what I'm doing wrong here? EDIT: Now it doesn't seem to work on SSL too :(
However in Firefox, it fails until I
start the Firebug console. That's when
the handshake happens and the data is
displayed.
Sounds like this might be a console.log() problem. Firefox will hang if you call console.log() without actually having a console open.
Related
I'm not sure why I have this error. Everything seems to be running fine and I don't have the error in Safari but when I open Chrome, it seems to not be happy.
Some context; I am running node and doing some single page d3 dabblings. I'm not developing any chrome extensions so I'm confused where this is coming from.
Similar but didn't help SO post
Has anyone managed to use websockets with latest firefox (29.0.1). Connection is established but no messages are sent to the server or received from the server.
Also tried to run http://www.websocket.org/echo.html example against my server and websocket.org but nothing. Everything works perfectly in older firefox and chrome.
Does anyone know what could cause it?
You have to enable the websocket:
open about:config in firefox toolbar as:
then setting the network.websocket.enabled preferences to true
Finally re-try to http://www.websocket.org/echo.html
I'm having a really weird bug in my HTML5 script. I wrote a sharepoint app completely in OData which uses a few HTML 5 webworker to do the number crunching in the background. This works perfect on all major browsers (FF, IE10+ Chrome, ...). However, when I perform a refresh or browse to the page again. The script still works as intended on FF and Chrome, but hangs on IE.
In my network view I see a request for the Worker.js file, but with a 304 NOT MODIFIED response. IE then just hangs there on that request with a status of (Pending). This issue only gets resolved when I clear my browser cache.
I correctly close all my threads with self.close().
Any idea what the issue could be? I'm not sure if it's a code issue, a browser issue or a server side issue but I can replicate the bug on Sharepoint online as well as on a local server. The whole project is JS only, so I can't modify headers as a workaround either.
UPDATE: I ran exactly the same code outside of a sharepoint environment, and it worked perfectly. Issue is Sharepoint related.
using a time based querystring parameter prevents caching showing http status 200 on each refresh. tested on latest chrome, ie, ff;
var opus = new Worker("worker.js?q=" + new Date().getTime().toString() );
to be honest this a long shot as i do not have sharepoint right now
SharePoint sends the header:
Content-Disposition: attachment; filename="xyz.js"
X-Download-Options: noopen
and the IE Web Worker Implantation then does not run this web worker. (Tested in IE11) In the IE Network Monitor the request still on pending, even the Response text is visible.
I know so fare two workarounds:
Place the web worker js in the layouts folder (needs a Farm Solution, with the downside of this)
Set the Browser File Handling for the Web application to Permissive (maybe your security is not amused)
How do i debug javascript in opera mini?
I have already installed opera mini emulator.
can someone help me how do i debug javascript remotely with dragonfly (firebug equivalent of opera)?
My script does in work in all other browser but not in opera mini
Opera Mini supports console API like this:
server:console?post=http://url/to/your/script
OR
You can dump your log data to source and get source using this command(this fill display source code of current/last page for your device):
server:source
OR
Use remote console services like jsconsole.com. You add script tag with jsconsole script and key. After this use this key on jsconsole site to get the log.
NB: jsconsole script rewrites console.log calling via ajax request
There is, at least for now, no support for debugging a javascript directly in Opera Mini.
You can use document.write to output progress/debug messanges, that is about the extent of debugging posibilities.
Could you point to the script, or at least describe what it is trying to do?
Opera Mini is fairly different from a normal browser, scripts are run on the transcoding servers, and the result of the run is then passed to the client, which can not in fact run scripts.
The client can then pass on clicks and some other events to the script when the user interact with the page, which might change the state/look of the page on the server, which is then sent to the client.
I have a weird error that I can not solve.
My implementation WebSocket works perfectly. The browser connects to the server, exchange their keys and the connection is fully established! The server starts sending messages to clients (visible in the network traffic).
But on my PC, all browsers (Chrome, Firefox, portable or not), the "onMessage ()" is correctly interpreted ... but only at the end when I turn off the server! In other words, if I put an alert () to each onMessage (), during exchange, I did absolutely nothing. But once I cut the server, I receive all alerts at once!
Yet on my MacBook everything works perfectly.
This ironic is it that behavior that affects all of my browsers on my PC. I run under Windows 7.
Thank you in advance ;)
I've finally found the issue !
If you have some troubles with Websockets, just disable the SSDP discover service on Windows.
net stop SSDPSRV
I ran into a similar issue recently. web server runs a separate SSDP discovery process to find uPnP devices on the network. When I had SSDP enabled, my websocket connection was always closed. Disabling SSDP solved it. But I haven't had a chance to investigate why.