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.
Related
Firefox is moving towards the WebExtensions standard which promises improvements in stability, cross-browser compatibility, and more security. At the same time they're gradually dropping support for legacy add-ons (bootstrapped extensions, add-on SDK, etc.).
Unfortunately, the WebExtension APIs are much less powerful than legacy add-ons which by contrast have full control over the browser. I fully understand the motivation for the switch, but the features my add-on provides just can't possibly work with limited capabilities of a WebExtension.
What are my options to continue developing a legacy add-on with as few cutbacks as possible? How do other add-ons that won't work as a pure WebExtension solve this problem? Are there any niche projects dedicated to maintaining some sort of legacy extension "hack", or will I have to heavily modify Firefox myself to get any legacy add-ons installed in the future?
(I'm aware that I won't be able to submit my add-on to AMO or get it signed by Mozilla and that supporting full extensions is a potential security risk. But since my add-on is targeting a tech-savvy audience, I'm not too concerned about moderately complex workarounds.)
As the magic 8 ball says: "Cannot predict now".
The reality is that we don't know yet what is going to be required to continue to run non-WebExtensions based add-ons past the release of Firefox 57. All we know is that Mozilla has stated that for Firefox 57:
Firefox will only run WebExtensions.
AMO will continue to support listing and updating legacy add-ons after the release of 57 in order to have an easier transition. The exact cut-off time for this support hasn’t been determined yet.
It had previously been stated that the restriction to WebExtensions-only would only apply to the Release and Beta channels, so:
It may be possible to continue to run non-WebExtension based add-ons on:
Developer Edition
Nightly
Unbranded Release and Beta (unknown status)
It is currently unclear if these will actually be possibilities. If they will be possibilities, it is unclear for how long it will remain possible for older add-ons to function (both due to changes to Firefox and/or non-WebExtensions being intentionally disabled). The fact that AMO will continue to support listing and updates to non-WebExtension add-ons is an encouraging sign that we will still be able to use them in Firefox releases that are not the main Release and Beta channels.
Other options include:
The Firefox ESR 52 release. The pattern is that this would be supported through the normal release of Firefox 60, or so. Personally, I feel that Mozilla should plan to have an ESR release prior to any major changes in functionality (i.e. have a Firefox 56 ESR), but that does not appear to be how Mozilla does things.
The various forks that have been made of Firefox. Each fork would have to be checked to see what their plans are for this change.
Any new fork made specifically to continue to support non-WebExtension add-ons.
A hack may be determined to re-enable non-WebExtension support, similar to the one that exists to disable checking for add-on signing.
You should keep in mind that the plans are for Firefox to fundamentally change in the future. A significant reason for moving away from the more capable add-on types (non-WebExtensions based extensions along with complete-themes) is to allow Firefox to be changed without the need to consider maintaining compatibility with more capable add-ons which rely on the internals of Firefox for their operation. When, exactly, these breaking changes will be rolled out is unclear.
Personally, I'm in a similar boat. None of my released add-ons are possible to move to WebExtensions. Many of the other add-ons which I use are clearly not possible to move to WebExtensions. Frankly, I'm not looking forward to using Firefox without the capabilities some of those add-ons provide. Thus, I will be continuing to look at what options are available as we get closer to Firefox 57.
However, even if I find no option to use more capable add-ons after Firefox 52 ESR is EOL'ed, I may continue to use Firefox. My primary reason for doing so instead of switching to Chrome would be the fact that Firefox extensions go through a review process, whereas Chrome extensions released though the Chrome store can be very bad from the point of view of both security and privacy.
Regarding your question:
Are there any niche projects dedicated to maintaining some sort of legacy >extension "hack", or will I have to heavily modify Firefox myself to get any >legacy add-ons installed in the future?
Besides the previously said FF52ESR, at least, there are 2 alive projects based in Firefox code that are focused in keeping compatibility with legacy extensions.
Waterfox 56 (updated and compatible with legacy addons and webextensions)
Basilisk 201804 (updated and based in FF52, targeting v55)
On the other hand you have Palemoon 27.x which also is still under support but it is based in pre Australis FF interface, so it will be compatible with old-legacy addons.
Download and install latest Nightly Firefox (https://www.mozilla.org/en-US/firefox/58.0a1/releasenotes) (you can right click on the icon, hit Properties, and then add -no-remote -p to the Target address, as in "C:\Program Files\Nightly\firefox.exe" -no-remote -p which will then enable you to use more than one Profile)
In about:config (paste in address bar and hit Enter key) look for extensions.legacy.enabled and right click and toggle it to true in.
Download "anyway" the latest development version of TMP, (https://addons.mozilla.org/en-US/firefox/addon/tab-mix-plus/versions/0.5.0.5pre.171027a1) to your download folder (since Nighlty will not install it normally), then under File go to Open File and navigate to that file (with the /xpi extension) in your download folder, and install it, and restart Nightly.
Unlikely that this will work with the standard Firefox 57+ release, but TMP developer is working on the require rewrite. May God help him.
IE has a handy debug feature that lets you emulate older versions of IE (7-10). Is there a similar feature as an addon for Firefox/Chrome that lets you, for example, turn back Chrome to only have the features it had a few versions ago? Or in Firefox test a site without the latest Firefox versions' CSS features? Or roughly show what a site would look like in IE7 by removing border-radius, shadows and advanced CSS effects, while not actually changing the stylesheets as loaded in the browser?
It seems effectively possible to remove JS features just on one page - for example, window.ArrayBuffer = undefined would cause lack of ArrayBuffer functionality as would happen in older browsers - but is there any addon, or api to write an addon, to go a step beyond "User agent switch" and remove features for testing?
Is there a similar feature as an addon for Firefox/Chrome that lets you, for example, turn back Chrome to only have the features it had a few versions ago?
Use a feature called profiles to install and run multiple versions of the browser in parallel:
Mozillazine: Using Multiple Profiles
Chromium: Creating and Using Profiles
Opera: How to make multiple profiles?
These are more future-proof than the Microsoft solution:
Note You may be able to use legacy document modes to emulate the behavior of earlier versions. Should you choose to do this, be aware that this is a temporary solution at best. Starting with Internet Explorer 11 Preview, document modes are consider deprecated and may not be supported in any future versions of the browser. For best results, you should update your sites and apps to use features and techniques supported by industry standards and multiple browsers.
Note Starting with IE11, document modes are considered deprecated and should no longer be used. Webpages that require legacy document modes to display properly should be rewritten to use features defined by modern standards. To learn more, see Compatibility changes in IE11.
But have caveats:
Chrome profiles are not backwards compatible, so storing the user profile on a network drive and using it with different versions of Chrome can cause crashes and data loss.
References
Compatibility changes in IE11
IE10 Compatibility Changes
Specifying legacy document modes
When to use Legacy Document Modes
Understanding the need for document compatibility modes
HTML5 Parsing in IE10
IE 10 Compat Inspector
IE 10, HTML5 and jQuery 2.x - JavaScript runtime error: 'JSON' is undefined
Interoperable HTML Parsing in IE9
Compatibility View and 'Smart Defaults'
Chromium: Supported Directory Variables
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.
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.
Many of the upcoming generation of browsers (FF 3.1, IE8) are going to support cross-domain XMLHttpRequests in one fashion or other (with security concerns, as long as the server opts in, etc).
Is the same bit of functionality going to be in WebKit?
FF: https://developer.mozilla.org/en/Cross-Site_XMLHttpRequest
IE: http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
Basic support for this was added to WebKit in May (see this patch). There are have been a number of other patches since then cleaning it up and refactoring bits of WebKit to deal with the changes entailed as well as tracking changes to the spec. Since the spec had changes recently (and webkit was updated with them 3 days ago) I think it is safe to assume no currently shipping browsers support it, but that most of them will in the future, and the current WebKit nightlies are tracking the standard fairly closely.
I think this is really up to the standard (http://www.w3.org/TR/XMLHttpRequest/) rather than the browsers framework, or javascript engine.
In fact I fully disagree with Microsofts decision to implement their own stuff that has nothing to do with the W3C standard. The web is a mess today mostly because of Microsofts ugly implementation of things.
As per WebKit, they seem to be pretty up-to-date with W3C.
Here's also a good article about this: http://ajaxian.com/archives/the-fight-for-cross-domain-xmlhttprequest
If you're looking for other ways to communicate cross-domain using ajax style (without using the XMLHttpRequest object), you should check out JSONP, it is currently fully supported on all browsers.