Here is the result from one of my desktops:
http://websocketstest.com/result/239749
Websockets are fine in Firefox, but no other connection can be made.
For some reason this website works perfectly:
http://demo.kaazing.com/forex/
In the firebug I can see that somehow kaazing streams the data and rotates the request every 500kbs.
Any ideas?
asdad
It looks like you're using Firefox 10.0.2, released in Feb 2002 - well over a year ago. As far as WebSocket support is concerned, this feels like an eternity...
One of the biggest challenges with WebSocket as a technology is that not everybody is on the latest and greatest browser version. Users of old desktop browsers (especially IE), Android (with default browser), and older iOS will all face this challenge.
The reason why Kaazing works is that it uses clever WebSocket emulation techniques: when native WebSocket support is not available in the browser, the connectivity falls back to alternative techniques that are very close in performance to a native WebSocket connection. If interested, you can learn more about the Kaazing emulation technology that works in all the older browsers, including IE6.
Related
I'm building a web application that is aimed at developers. I assumed that most web developers would be using a modern browser, and thus would have support for WebSockets. Is there any need, then, for socket.io? Or maybe I'm just being naive about this?
WebSockets support is very limited. The current release version of Internet Explorer (IE 9) doesn't even support the current WebSockets specification. You need IE 10+, Firefox 11+, Chrome 16+, or a nightly build of Safari.
http://en.wikipedia.org/wiki/WebSocket#Browser_support
So it's a pretty big assumption that most web developers are using a browser that supports it.
Also, think about enterprise web developers. Often their corporate users are all running some older version of a browser (almost always IE) that the company has standardized on (usually to support some older Line of Business app).
In fact, 7% of all internet users and 25% of Chinese users are still using IE 6.
There will likely be plenty of need for socket.io for the foreseeable future.
Many proxy servers and firewalls break websockets. Use http://socket.io-test.com to test.
I have a mobile web app running as client-side JavaScript using Opera Mobile 10 on Windows Mobile 6.5 Professional (on a Motorola MC9500). (I've tried IE Mobile 6, but it doesn't support the canvas element nor enough JavaScript to be useful for my purposes.) I need this app to exchange messages with a native app on the same device. Because JavaScript is sand-boxed and I don't have access to ActiveX, it seems that one way to do this is to send/receive messages via AJAX through an intermediate server on the same device. Does anyone have a recommendation for an HTTP server that will run on Windows Mobile 6.5 Professional? This server should be able to cache the messages with persistent storage, e.g., SQLite.
I'm currently looking at PocketHPH, a PHP server. I have also found Padarn, an ASP.NET web server. I welcome any suggestions on small web servers that are better suited to this task.
Thanks.
Here's some clarification of my original question. The original web app is running on iPhone using Safari. It's a pretty complicated JavaScript app which I didn't write. So I'm trying to move it to Windows Mobile without having to rewrite the thing as a native app. The reason I'm moving it is because we're partnering with another company that has an existing native app that must run on an MC9500 which runs Windows Mobile 6.5 Pro. So I don't have any control or access to the code of the native app. However, our web app must exchange messages with the other company's app. Hence, many of the constraints, e.g., I can't use IWebBrowser2 from the native app. The other company's developer could try, but it doesn't look like he's going to go for that because there are much smaller things that he won't do. My understanding is that I can only use ActiveX from IE Mobile, not from Opera Mobile. However, there are several JavaScript features that IE Mobile 6 doesn't support. So I might be able rewrite the entire JavaScript app to make IE happy (I had already done quite a bit of rewriting before switching to Opera Mobile which has a much better JavaScript engine), but it would probably be easier to just rewrite it as a native app. It might be possible to engineer out the canvas element, but again if I'm going to do that, I might as well bite the bullet and rewrite the whole thing as a native app. So much for trying the "easy" route of porting to another web browser.
I think PocketHPH is giving me what I need. It is a compact PHP server that runs on Windows CE devices. It includes SQLite3. It is working on my Windows Mobile 6.5 Professional device: a Motorola MC9500.
You can download it here: http://mobileleap.net/hph/
However, it looks like it hasn't been updated since 2007. So it might be a risky thing to rely on.
I have been able to send/receive AJAX requests/responses from a web-based Javascript app running in Opera Mobile using Cross-Domain Messaging. I wrote PHP for the server that stores/retrieves the messages to/from the SQLite3 database.
One problem I'm having though: the AJAX cannot connect to the server when the device is offline, even though it is entirely a local connection. For more info: https://stackoverflow.com/questions/9307745/cannot-connect-to-127-0-0-1-when-offline-using-windows-mobile-6-5-professional-e
I found this plugin, for Firefox, on Google and it looks like perfect to test if my site works well on all major browsers. It changes the browser's user-agent and emulates almost all versions of all browsers on any OS, including mobile. Looks like perfect. My question is: can i trust 100% on this plugin? It really give me the same effect as if i were using other browser (ie6 for exemple)?
It really give me the same effect as if i were using other browser (ie6 for exemple)?
No. Changing the user-agent string does not mean you are changing the browser's rendering engine - it just sends a different browser signature to the server. The actual rendering will always be Firefox's, at the sites will always look as they do in Firefox.
See these questions on how to test sites in different browsers:
Browser testing - Ideas on how to tackle it efficiently
https://stackoverflow.com/questions/464089/simulators-emulators-for-mobile-browser-testing
It does not affect the rendering engine of your browser. It only pretends to the server to be a different browser, so if the server has e.g. a special IE6-optimized version it will send you this version instead.
Essentially, this is mostly useful to access web pages that claim to not support your browser by pretending that you have a supported version.
For testing cross-browser compatibility it is useless.
You can get free screenshots from a wide array of browsers at http://browsershots.org/
that is a very useful site, but won't help you test JavaScript interactions.
The question's pretty straightforward and the old topic is here. I'm hoping to get up-to-date answers since IE9's gonna be released this March 14, 2011.
In addition, I would also like to ask when will Firefox and Opera be supporting WebSockets?
I've been following both the development of IE9 and I also participate in the HyBi WG (WebSockets protocol). Microsoft has been keeping the demo implementation of WebSockets up to date with the latest revisions of the protocol, however, I suspect that the initial release of IE9 will not have built-in WebSockets support. It will probably not be until IE10 unless they start to see it as a big competitive disadvantage in which case we will likely see it added in a IE9 update before IE10.
Firefox will likely support WebSockets in an update to FF4 or with FF5 (but the plan is that 5 will come out this year). Also, you can turn on the current implementation in FF4 using a about:config option.
I have no idea about Opera. They are interesting in the protocol but they've been pretty silent on the HyBi list.
Also, if you need WebSockets right now you can always use the Flash shim/fallback web-socket-js.
Update:
I forgot, Opera 11.00 does have WebSockets support built-in but disabled. Go to opera:config and search for WebSocket.
So in summary, just about every modern browser has WebSockets support in some way either built-in and enabled (Chrome, Safari, iOS), built-in but disabled (FF4 and Opera), as a downloadable add-on (IE9), or using the web-socket-js Flash emulator (everything except iOS).
Nope, The RTW version of IE9 does NOT support a websocket type... :(
UPDATE: The IE team is developing websockets for their browser, but it's not included in the initial release because the standard is in a fluid state. Although the implementation is stable, the standard isn't. If you want to test it out in IE9, you can by downloading it here:
http://html5labs.interoperabilitybridges.com/
You can hear more about it by listening to this DotNetRocks podcast:
http://www.dotnetrocks.com/default.aspx?showNum=648
Best regards.
IE9 does support WebSockets but not as a "built-in" functionality. You have to download it as a plugin from http://html5labs.interoperabilitybridges.com
The reason given by microsoft for not including in default setup is - the standard is unstable and keeps changing and in default setup only stable HTML5 standards shall be included.
So in a way IE10 as of now will also not include.
The HTML5Labs site will provide "experimental" support to unstable standards.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
Will IE9 support WebGL and/or WebSockets?
Most answers to the question "When will browser X support HTML5 feature Y?" are answered by When Can I Use. In addition to list past, current and future support each item also generally has links to relevant news.
WebSockets
WebGL
Update:
Microsoft has been actively participating in the IETF HyBi working group (WebSockets protocol) and also participating in W3C work on the WebSockets API. The IE 10 preview release has WebSocket support built-in so it looks very likely that we will soon see a official release version of IE with WebSockets.
WebGL in IE still looks pretty uncertain. Microsoft claims fundamental security issues with the design of WebGL, but I suspect it has more to do with the fact that Microsoft has a vested interest in promoting their own DirectX framework rather than OpenGL (which is what WebGL is based on).
As of a few months ago, the IE9 team hadn't made a decision about supporting WebSockets, and they didn't seem to see the point to WebGL.
WebGL seems not to be include in IE's strategy because of DirectX.
Anyway google already worked on that with the ANGLE project.
http://code.google.com/p/angleproject/
The IE team added a WebSocket implementation at HTML5 Labs which is their testing ground for new implementations. Chances are high that WebSockets will make it in IE9
You can look at the current release notes for the platform demo - there is no mention of either WebSockets or WebGL.
There are many discussions of the security issues of WebGL. I first heard of it on one of Steve Gibson's podcasts. Since it gives much lower level access to both the operating system and the hardware any flaw can be exploited much more severely. A quick Google search found this article with descriptions and video of some of the flaws: http://www.contextis.com/research/blog/webgl2/
Microsoft seems quite reluctant to implement WebGL in IE, since OpenGL is a competitor to DirectX. So I think it's unlikely we'll see WebGL in IE in the near future.
I’ve started an Open Source project called JebGL that can serve as a fallback for IE users. It’s a Java applet that when finished will serve as a plugin replacement for a WebGL canvas. It’s still in the early stages of development, but you can check out the demos at http://jebgl.googlecode.com
Right now, the Microsoft IE team is struggling to get HTML 5 and SVG (2D graphics) into Internet Explorer 9. Other web browser makers have been shipping with those standards built in for years.
Apple Safari, Google Chrome, and Mozilla Firefox all run fine on Windows. Takes one mouse click to launch a different browser. Takes a year or two to see what Microsoft might do.
IE progress has consistently been glacially slow this whole decade.
No, IE does not have WebGL support now and betas from other browser makers already run it. IE9 will not catch up with contemporary web standards like WebGL, just ones that have been out for several years or more.
IE9 is not a cross platform web browser either. It will only run on certain specific versions of Microsoft Windows. Just run one of the standard web browsers and you can see what WebGL can do. Their current betas are running some impressive WebGL demos now.
As a fallback until Microsoft adds WebGL support, the Google Chrome Frame beta currently supports WebGL.
RE: WebSockets: No. The target was websocket support in IE10. Tests show that it only has partial support.