Supported browsers

One of the goals of easyXDM is to support all browsers that are in common use, and to provide the same features for all. One of the strategies for reaching this is to follow defined standards, plus using feature detection to assure the use of the most efficient one.

Non-standard methods may also be used where appropriate.

The two primary techniques used are


window.postMessage is defined in the draft HTML5 specification, and is currently implemented in all the major browsers.


This is a transport that is specific for IE6 and IE7, and that offers speeds similar to postMessage (if not faster).

Nix relies on the fact that the in IE<8 the window.opener property can be read and written to from both the parent and the child window, meaning that it can be used to transfer proxy methods.

In order to not introduce security risks by leaking context between the windows, a VBScript COM object is created on the fly serving as a proxy.

This technique was originally found in the Apache Shindig project.

Additional techniques available

Fragment Identifier Messaging (FIM)

FIM is one of the oldest and most used methods for cross-domain messaging, and there are several papers on the subject, as well as several ways to implement it.

This technique uses the FIM part of the URL to transfer messages and so has some limitation on length of each message fragment, as well as being vulnerable to ‘dropped’ messages. easyXDM negates these limits by implementing both a fragmenting and queuing mechanism and a mechanism that verifies that messages are received.

Since using FIM is inherently relatively slow due to the fragmenting and verification easyXDM also provides a mechanism using the property. This requires the presence of a special file on both domains, but enables you to reach speeds similar to that of postMessage.

Verified support

A proper matrix will be created based on the test suite.
For now the library is tested with IE 6, 7, 8, and current versions of Opera, Chrome, Firefox and Safari.
As the library uses feature testing (and not browsersniffing) it is believed that the tests covers the relevant browsers capabilities.

If you know of a browser that does not pass the final test in the test suite, then please leave a comment with the details!

This entry was posted in Features and tagged , , , , , , , , , , , , , , , , . Bookmark the permalink.
  • Michiel

    Great lib! Now trying to get it working in a project I’m doing. Few questions though:

    1) is the ‘local: ‘name.html’ file needed?

    The reason for this question is that I’d like for the customer page to only include 1 single JS file that does the job for me. I’d like to use rpc or XD Ajax but cannot ask my users to also include the name.html file. Does this have a crossbrowser effect or is it purely performance the name.html file is used for?

    2) Do I need json2.js?
    As said, I’d like to use this as a cross domain ajax implementation – however – the json2 file adds quite a lot to the footprint. So the question is, do I need to include this file if I want to support cross domain Ajax from IE6 and up (+plus all other browsers of course)?

    Would be great if you could provide some answers. Also – any plans to convert this thing into a native jQuery plugin so jQuery can transparently support cross-domain Ajax? I think it would be a killer plugin (worthy of a place in the jQuery Core even).


    • 1)
      No, local set on the provider, and local and remoteHelper on the consumer is only needed if you want the fast NameTransport to be used instead of the slower HashTransport when no other transports are available (only very old browsers).

      2) needed if you want to use the RPC feature in a browser that hasn’t got a native JSON feature. The current examples of cross domain ajax use the RPC feature, but it can be done using a Socket, but with a bit more work involved.

      Regarding jQuery, no, there are no such plans, nor is it natural in any way.
      easyXDM is a framework agnostic library usable for all, and though it could be wrapped within jQuery, the question of why still stands (I was actually discussing this with Paul Irish the other day).
      For those who want this feature, they should use easyXDM directly, and know what it means to use it (as you could potentially expose your server resources without knowing it).
      But sure, it is possible to wrap the native post/get methods and instantiate an easyXDM object internally when the call is going to a remote domain, but that would also mean that you would need to tell easyXDM where to find the remote endpoint, something that means that you will need to break the standard post/get paradigm anyways – so why not just use easyXDM directly right?

      I hope that answers your questions 🙂


      • Michiel

        That was fast 😉

        Your answers are clear – thanks!
        One more for you – I keep getting an error (firebug) at the moment, trying to use RPC:

        var data = serializer.parse(message);

        Not doing anything advanced – simple remote method call. Can’t seem to find out why it breaks on this line. Any clues?

        • It’s kind of hard to debug without knowing the error message you know 😉
          Do you mind continuing this on the mailing list?

          • Michiel

            Hehe – for sure! I’ll subscribe to the list.


  • dhar

    hi i downloaded your examples and it works perfectly fine on firefox and chrome, but it’s not working on IE8 and under, can you help me with this?

  • lukeyb152

    Hi, I’ve been experimenting with this for some time now. I’m having a fairly trivial problem. Frameborders in IE8 and below will not go away.

    If you could help, that would be great! Thanks

  • Aktham Nassar


    easyXDM working just fine in IE8, but in IE11 I am getting a javascript error from provider page:
    File: Provider.html, Line: 24, Column: 18927
    “Unable to get property ‘parse’ of undefined or null reference”

    Can you please help?