easyXDM – extremely easy cross-domain scripting

easyXDM is a javascript library that uses available techniques to provide a means of transporting messages and/or method calls between windows in different domains, in short, by-passing the same-origin policy and letting you call methods across the domain boundry.

This is perfect if you plan to provide a client-side API (e.g Facebook Connect) on your web site as you can expose a method in as little as 7 lines of code.

var remote = new easyXDM.Interface({}, {
    local: {
        doMagic:{
            method: _privateMethod
        }
    }
});

This can be consumed by a client by using

var remote = new easyXDM.Interface({
   local: "../hash.html",
   remote: "http://apiprovidersdomain.com/api.html"
},{
    remote: {
        doMagic: {}
    }
});

and can then be called by using

remote.doMagic('argument1',2,function(result){
    alert(result)
}

In this CodeProject article I present an example on how easy it is to do this, and in the extensive documentation there are links to several demos showing everything from sending simple strings to letting two applications from different domains send arbitrary objects back and forth, even using older browsers like IE6.

The demos are repeated here

This library was earlier on called easyXSS, but due to the name being kinda ambiguous (someone say vulnerability), I decided to change it to easyXDM, short for easy cross domain messaging.

If you want to sneak a peek at the sourcecode, you can see the fully documented debug version here. The minified version weighs in at only 1.46KB gzipped.

The library is very flexible, allowing you you choose exactly how much of the work you want to handle yourself, the base functionality is transferring string messages.

Some of the features are

  • transport classes for transmitting strings
    • postMessage where supported OR
    • hash fragment using the resize event for invisible iframes
    • hash fragment using polling for visible frames
  • channel class for transmitting aribitrary data
  • interface class for setting up methods to be exposed/consumed
  • debug build with extensive logging for easy debugging
  • works in all browser (run the test suite)

The library also support both visible and invisible iframes, so you can either access the remote domain transparently, or you can expose the remote domains document for direct interaction (sign in etc.).

<ul>
<li>
<a href=”http://consumer.easyxdm.net/example/transport.html”>Sending plain string messages using the easyXDM.Transport.BestAvailableTransport class</a>
</li>
<li>
<a href=”http://consumer.easyxdm.net/example/data.html”>Sending data (objects)  using the easyXDM.Channel class</a>
</li>
<li>
<a href=”http://consumer.easyxdm.net/example/methods.html”>Exposing and invoking methods using the easyXDM.Interface class</a>
</li>
<li>
<a href=”http://consumer.easyxdm.net/example/xhr.html”>Calling an ajax method from the remote domain</a>
</li>
<li>
<a href=”http://consumer.easyxdm.net/example/index.html”>Bridging two web applications</a>
</li>
</ul>

Tags: , , , , , ,

This entry was posted on Thursday, August 20th, 2009 at 17:03 and is filed under easyXDM, programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • lovespring

    How can I move the 'hash.html' to the remote side? say, I want create a bookmarklet, and inject easyXDM to local page, but I cannot make all local domain has "the hash.html" file

    • http://kinsey.no/ Øyvind Sean Kinsey

      Well if you only need to support newer browsers that support the HTML5 postMessage specification, then you can safely reference a non-existing hash.html, if not, then there is no way of doing this. Legacy cross-domain communication demands a file present on the local domain, and the option is then whether to be able to use any file or a specific file. easyXDM needs a specific file for efficient usage, but maybe we should re-implement the content-agnostic method as well as a fallback…

      • lovespring

        Thanks for your reply.
        I think, the hash.html is used to eliminate the fragment identifier showing in the top window.
        Sometimes, we can inject script but cannot always have the way to inject the hash.html.
        so, I would be better if we can config easyXDM like this:
        local: (this top window)
        remote: (something in the remote domain)

        • http://kinsey.no/ Øyvind Sean Kinsey

          Yes, falling back to using the current document is the last resort, this is actually what Facebook Connect does.This is not as efficient as using hash.html, but it is a valid last resort. I will make a feature request for it.

          • http://benn.org/ meinhard

            The users of our planned API sometimes do not have the possibility to upload HTML files. So the current hash.html solution would be a showstopper for us.

          • http://kinsey.no/ Øyvind Sean Kinsey

            Hash.html is only used to support older browsers that does not support the postMessage interface, so if you can live without this, it will still work.
            I’m going to see if I can get something to work that doesn’t rely on the user having to upload files – maybe by using the robots.txt file or something, but this will not be as efficient.

          • http://benn.org/ meinhard

            Thanks for considering. Unfortunately the market share of StupidBrowsers (TM) is still quite high. I went for the jQuery postMessage plugin for now, which uses location hash modification as fall-back. I will keep an eye on easyXDM.

          • http://kinsey.no/ Øyvind Sean Kinsey

            Just consider the consequences of how the jQuery plugin falls back to modifying the hash of the parent frame, and how it needs the exact url of the page.
            One of the important goals of easyXDM is to be nonobtrusive, that is, not modifying any of the behavior on the primary page, and modifying the url of the main page, and also jQuery as a dependency, is what I consider obtrusive.
            I’ll release a version that will be able to utilize any file located on the main domain, like robots.txt or favicon.ico later tonight – I’ll give you a heads up.

          • http://kinsey.no/ Øyvind Sean Kinsey
  • lovespring

    How can I move the 'hash.html' to the remote side? say, I want create a bookmarklet, and inject easyXDM to local page, but I cannot make all local domain has "the hash.html" file

    • http://oyvind.kinsey.no/ oyvindkinsey

      Well if you only need to support newer browsers that support the HTML5 postMessage specification, then you can safely reference a non-existing hash.html, if not, then there is no way of doing this. Legacy cross-domain communication demands a file present on the local domain, and the option is then whether to be able to use any file or a specific file.
      easyXDM needs a specific file for efficient usage, but maybe we should re-implement the content-agnostic method as well as a fallback…

      • lovespring

        Thanks for your reply.
        I think, the hash.html is used to eliminate the fragment identifier showing in the top window.
        Sometimes, we can inject script but cannot always have the way to inject the hash.html.
        so, I would be better if we can config easyXDM like this:
        local: (this top window)
        remote: (something in the remote domain)

        • http://oyvind.kinsey.no/ oyvindkinsey

          Yes, falling back to using the current document is the last resort, this is actually what Facebook Connect does.
          This is not as efficient as using hash.html, but it is a valid last resort. I will make a feature request for it.

          • http://benn.org/ meinhard

            The users of our planned API sometimes do not have the possibility to upload HTML files. So the current hash.html solution would be a showstopper for us.

          • http://oyvind.kinsey.no/ oyvind.kinsey

            Hash.html is only used to support older browsers that does not support the postMessage interface, so if you can live without this, it will still work.
            I’m going to see if I can get something to work that doesn’t rely on the user having to upload files – maybe by using the robots.txt file or something, but this will not be as efficient.

          • http://benn.org/ meinhard

            Thanks for considering. Unfortunately the market share of StupidBrowsers (TM) is still quite high. I went for the jQuery postMessage plugin for now, which uses location hash modification as fall-back. I will keep an eye on easyXDM.

          • http://oyvind.kinsey.no/ oyvind.kinsey

            Just consider the consequences of how the jQuery plugin falls back to modifying the hash of the parent frame, and how it needs the exact url of the page.
            One of the important goals of easyXDM is to be nonobtrusive, that is, not modifying any of the behavior on the primary page, and modifying the url of the main page, and also jQuery as a dependency, is what I consider obtrusive.
            I’ll release a version that will be able to utilize any file located on the main domain, like robots.txt or favicon.ico later tonight – I’ll give you a heads up.

          • http://oyvind.kinsey.no/ oyvind.kinsey
  • Edi

    IE7 is giving me huge problems…

    for start, onReady is never called (IE 7.0.5730.13).

    then, when using Async, callback function is in some cases never called back (using user function as callback).

    in debug mode i get for sender:
    localhost-1251294014255:executing method callMethod
    localhost-1251294014271:sending message '{"name":"callMethod","id":1,"params":["rate","param1=1&param2=2"]

    and in remote (embedded div) i get:
    localhost-1251294014380:received request to execute method callMethod using callback id 1
    localhost-1251294014380:requested to execute async method callMethod
    localhost-1251294015396:sending message '{"id":1,"response":"{"return_id":"1","rating":1}"}' to http://localhost

    FIREFOX is also giving this at the end in sender log (missing in IE):
    localhost-1251294412319:onMessage
    localhost-1251294412324:received message 'default {"id":1,"response":"{"return_id":"1","rating":1}"}' from http://localhost
    localhost-1251294412329:interface$_onData:([object Object],http://localhost)
    localhost-1251294412333:received return value destined to callback with id 1

    and ideas?

  • Edi

    IE7 is giving me huge problems…

    for start, onReady is never called (IE 7.0.5730.13).

    then, when using Async, callback function is in some cases never called back (using user function as callback).

    in debug mode i get for sender:
    localhost-1251294014255:executing method callMethod
    localhost-1251294014271:sending message '{"name":"callMethod","id":1,"params":["rate","param1=1&param2=2"]

    and in remote (embedded div) i get:
    localhost-1251294014380:received request to execute method callMethod using callback id 1
    localhost-1251294014380:requested to execute async method callMethod
    localhost-1251294015396:sending message '{"id":1,"response":"{"return_id":"1","rating":1}"}' to http://localhost

    FIREFOX is also giving this at the end in sender log (missing in IE):
    localhost-1251294412319:onMessage
    localhost-1251294412324:received message 'default {"id":1,"response":"{"return_id":"1","rating":1}"}' from http://localhost
    localhost-1251294412329:interface$_onData:([object Object],http://localhost)
    localhost-1251294412333:received return value destined to callback with id 1

    and ideas?

  • Edi

    huh, it's quite complicated on my side… have to isolate it first… in mean time i would be grateful if you would try to figure according to the post i sent.

    thank you

    • http://kinsey.no/ Øyvind Sean Kinsey

      Im looking into it now, it seems some of my recent changes (even though minor) causes IE7 to crash badly on my computer :(But if you get it working in FF, then you can just replace the library when I have a new version (I'll try to do it today).

      • http://kinsey.no/ Øyvind Sean Kinsey

        Actually, it seems it was my virtual pc that was acting up, after a while IE stopped crashing.
        The conclusion is that all my tests work on IE6, IE7 and FF3.5, I have no reason to believe they should not work in any other browsers as I have previously tested with Opera and Safari as well.

  • Edi

    huh, it's quite complicated on my side… have to isolate it first… in mean time i would be grateful if you would try to figure according to the post i sent.

    thank you

    • http://oyvind.kinsey.no/ oyvindkinsey

      Im looking into it now, it seems some of my recent changes (even though minor) causes IE7 to crash badly on my computer :(
      But if you get it working in FF, then you can just replace the library when I have a new version (I'll try to do it today).

      • http://oyvind.kinsey.no/ oyvindkinsey

        Actually, it seems it was my virtual pc that was acting up, after a while IE stopped crashing.
        The conclusion is that all my tests work on IE6, IE7 and FF3.5, I have no reason to believe they should not work in any other browsers as I have previously tested with Opera and Safari as well.

  • http://mylivescore.no/ Kasper

    I am really on the scratch here. Been looking everywhere for some technique that could take data from my webpage (source) to another webpage (destination). The code the consumer should write/paste should only be some lines and of course with some parameters (like easyxdm? and adsense).

    Look at my page: http://www.mylivescore.no and click on one of the tournaments on the left. A table of teams will show up in the right (source). Each of these teams have their own webpage, and they would like to display this table on their webpage (consumer). Do I have to make an API first and then use easyxdm? I am really looking for some more advanced stuff than Iframe (because this is only the beginning), so please don't say Iframe :)

  • http://mylivescore.no Kasper

    I am really on the scratch here. Been looking everywhere for some technique that could take data from my webpage (source) to another webpage (destination). The code the consumer should write/paste should only be some lines and of course with some parameters (like easyxdm? and adsense).

    Look at my page: http://www.mylivescore.no and click on one of the tournaments on the left. A table of teams will show up in the right (source). Each of these teams have their own webpage, and they would like to display this table on their webpage (consumer). Do I have to make an API first and then use easyxdm? I am really looking for some more advanced stuff than Iframe (because this is only the beginning), so please don't say Iframe :)

  • http://kinsey.no/ Øyvind Sean Kinsey

    For easy inclusion of this table you have two options, either having the consumer insert a script tag pointing to a dynamically generated script on your domain, that would add the needed DOM elements, or by having an Iframe pointing to a url on your domain. These are the ONLY options you have.

    If you plan on more advanced scenarios I would use the iframe option much like in the example found here http://easyxdm.net/example/methods.html . This gives you the option of presenting an iframe with visible content (your table), as well as exposing/consuming methods across the boundary (and yes, these methods could involve XHR calls).

    Of course, if you start by going down the script tag path, then you could actually use the js to load all needed libraries (like json2, easyxdm etc) and also to insert the iframe. This way the consumer only needs to insert a single script tag.

    But eithe way, I'm gonna have to disapoint you, Iframes will be involved if you are looking for advanced functionality :). But this really should not be a broblem when using easyXDM.
    (and no, there is no other way ;)

    Du kan eventuelt sende av gårde en e-post om du lurer på noe mer :)

  • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

    For easy inclusion of this table you have two options, either having the consumer insert a script tag pointing to a dynamically generated script on your domain, that would add the needed DOM elements, or by having an Iframe pointing to a url on your domain. These are the ONLY options you have.

    If you plan on more advanced scenarios I would use the iframe option much like in the example found here http://easyxdm.net/example/methods.html . This gives you the option of presenting an iframe with visible content (your table), as well as exposing/consuming methods across the boundary (and yes, these methods could involve XHR calls).

    Of course, if you start by going down the script tag path, then you could actually use the js to load all needed libraries (like json2, easyxdm etc) and also to insert the iframe. This way the consumer only needs to insert a single script tag.

    But eithe way, I'm gonna have to disapoint you, Iframes will be involved if you are looking for advanced functionality :). But this really should not be a broblem when using easyXDM.
    (and no, there is no other way ;)

    Du kan eventuelt sende av gårde en e-post om du lurer på noe mer :)

  • http://diocakep.blogdetik.com/ dioramayuanito

    hello kinsey!
    i think you're cool kid now! :)

    i have 2 html textbox called 'lngit' and 'latit' and also a code in remote like this

    onData: function(data, origin){
    //alert("Received data from '" + origin + "':")
    for (var key in data) {
    //alert("Property '" + key + "'=" + data[key]);
    if (key=="longitude") {
    var lngme = document.getElementById("lngit");
    if (lngme!=null) {
    lngme.value = data[key];
    alert(lngme.value);
    }
    }
    if (key=="latitude") {
    var latme = document.getElementById("latit");
    if (latme!=null) {
    latme.value = data[key];
    alert(latme.value);
    }
    }
    }
    }

    and i've seen a successful message transport in alert() sent by a message producer,
    but why my lngit and latit html textbox value still empty string in browser?

    • http://kinsey.no/ Øyvind Sean Kinsey

      Sorry about the delay :)
      The code looks correct, and if you say that you did receive correct data earlier then there is no reason why the value of the input fields should not reflect that.
      The best way to debug this is to look through the easyXDM trace output and verify that the message is indeed correct, and then step through the code using e.g firebug and breakpoints..
      If you supply a url I could take a look.

  • http://diocakep.blogdetik.com dioramayuanito

    hello kinsey!
    i think you're cool kid now! :)

    i have 2 html textbox called 'lngit' and 'latit' and also a code in remote like this

    onData: function(data, origin){
    //alert("Received data from '" + origin + "':")
    for (var key in data) {
    //alert("Property '" + key + "'=" + data[key]);
    if (key=="longitude") {
    var lngme = document.getElementById("lngit");
    if (lngme!=null) {
    lngme.value = data[key];
    alert(lngme.value);
    }
    }
    if (key=="latitude") {
    var latme = document.getElementById("latit");
    if (latme!=null) {
    latme.value = data[key];
    alert(latme.value);
    }
    }
    }
    }

    and i've seen a successful message transport in alert() sent by a message producer,
    but why my lngit and latit html textbox value still empty string in browser?

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      Sorry about the delay :)
      The code looks correct, and if you say that you did receive correct data earlier then there is no reason why the value of the input fields should not reflect that.
      The best way to debug this is to look through the easyXDM trace output and verify that the message is indeed correct, and then step through the code using e.g firebug and breakpoints..
      If you supply a url I could take a look.

  • Luava liu

    hi, the easyDXM is very good, and I use it in my project…but some bug i cannot fix:
    My first app with https protocol, and with iframe inside the second app which is http protocol, thus, there’s some javascript error appear, can you tell me how to fix it ?

    • http://kinsey.no/ Øyvind Sean Kinsey

      Sorry about the delay, but I need a bit more information than that :)
      But as soon as you mix http and https you create a boundary due to the Same Origin Policy.

      If you could provide a link I could take a look at it..

  • Luava liu

    hi, the easyDXM is very good, and I use it in my project…but some bug i cannot fix:
    My first app with https protocol, and with iframe inside the second app which is http protocol, thus, there’s some javascript error appear, can you tell me how to fix it ?

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      Sorry about the delay, but I need a bit more information than that :)
      But as soon as you mix http and https you create a boundary due to the Same Origin Policy.

      If you could provide a link I could take a look at it..

  • http://blog.dotnetwise.com/ DotNetWise

    Google chrome crashes every time with your tests! It says Aw snap!
    A few times I could get these results. As you can see most of them fails:
    easyXDM test suite

    easyTest messages

    Running test 'Check that the library is complete'
    1ms, 0ms, 0ms – check for the presence of easyXDM succeeded!
    3ms, 2ms, 1ms – check for the presence of easyXDM.transport succeeded!
    3ms, 2ms, 0ms – check for the presence of easyXDM.serializing succeeded!
    3ms, 2ms, 0ms – check for the presence of easyXDM.configuration succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.Channel succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.transport.HashTransport succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.transport.PostMessageTransport succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.Debug succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.DomHelper succeeded!
    5ms, 4ms, 0ms – check for the presence of easyXDM.Url succeeded!
    Running test 'test easyXDM.transport.HashTransport using polling'
    Setup succeeded
    120ms, 91ms, 91ms – onReady is fired succeeded!
    710ms, 681ms, 589ms – message is echoed back succeeded!
    710ms, 681ms, 0ms – destroy succeeded!
    Running test 'test easyXDM.transport.HashTransport using onresize'
    Setup succeeded
    5737ms, 5001ms, 5001ms – onReady is fired failed! Failed due to timeout.
    5804ms, 5068ms, 67ms – message is echoed back succeeded!
    5806ms, 5070ms, 1ms – destroy succeeded!
    Running test 'test easyXDM.transport.PostMessageTransport'
    Setup succeeded
    10842ms, 5000ms, 5000ms – onReady is fired failed! Failed due to timeout.
    11842ms, 6000ms, 1000ms – message is echoed back failed! Failed due to timeout.
    11845ms, 6003ms, 3ms – destroy succeeded!
    Running test 'test easyXDM.transport.BestAvailableTransport'
    Setup succeeded
    16875ms, 5000ms, 5000ms – onReady is fired failed! Failed due to timeout.
    17875ms, 6000ms, 1000ms – message is echoed back failed! Failed due to timeout.
    17876ms, 6001ms, 1ms – destroy succeeded!
    Running test 'test easyXDM.transport.BestAvailableTransport with query parameters'
    Setup succeeded
    22896ms, 5000ms, 5000ms – onReady is fired failed! Failed due to timeout.
    23897ms, 6001ms, 1000ms – message is echoed back failed! Failed due to timeout.
    23898ms, 6002ms, 1ms – destroy succeeded!
    Running test 'test easyXDM.Interface'
    Setup succeeded
    28925ms, 5001ms, 5001ms – onReady is fired failed! Failed due to timeout.
    29927ms, 6003ms, 1001ms – void method failed! Failed due to timeout.
    30928ms, 7004ms, 1001ms – async method failed! Failed due to timeout.
    31928ms, 8004ms, 1000ms – regular method failed! Failed due to timeout.
    31932ms, 8008ms, 2ms – destroy succeeded!
    Test run complete

    • http://kinsey.no/ Øyvind Sean Kinsey

      I just tried it in the newest Chrome and can confirm that it crashes – the previous version did not.
      From what I can deduce its the hashprovider that causes it to crash when using the resize event instead of polling. Under normal use this will never occur as easyXDM will use the PostMessageTransport in Chrome and all other browsers that support this.
      But still, the library should not crash any browser – kinda funny how such simple code can do so :)

  • http://blog.dotnetwise.com DotNetWise

    Google chrome crashes every time with your tests! It says Aw snap!
    A few times I could get these results. As you can see most of them fails:
    easyXDM test suite

    easyTest messages

    Running test 'Check that the library is complete'
    1ms, 0ms, 0ms – check for the presence of easyXDM succeeded!
    3ms, 2ms, 1ms – check for the presence of easyXDM.transport succeeded!
    3ms, 2ms, 0ms – check for the presence of easyXDM.serializing succeeded!
    3ms, 2ms, 0ms – check for the presence of easyXDM.configuration succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.Channel succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.transport.HashTransport succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.transport.PostMessageTransport succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.Debug succeeded!
    4ms, 3ms, 0ms – check for the presence of easyXDM.DomHelper succeeded!
    5ms, 4ms, 0ms – check for the presence of easyXDM.Url succeeded!
    Running test 'test easyXDM.transport.HashTransport using polling'
    Setup succeeded
    120ms, 91ms, 91ms – onReady is fired succeeded!
    710ms, 681ms, 589ms – message is echoed back succeeded!
    710ms, 681ms, 0ms – destroy succeeded!
    Running test 'test easyXDM.transport.HashTransport using onresize'
    Setup succeeded
    5737ms, 5001ms, 5001ms – onReady is fired failed! Failed due to timeout.
    5804ms, 5068ms, 67ms – message is echoed back succeeded!
    5806ms, 5070ms, 1ms – destroy succeeded!
    Running test 'test easyXDM.transport.PostMessageTransport'
    Setup succeeded
    10842ms, 5000ms, 5000ms – onReady is fired failed! Failed due to timeout.
    11842ms, 6000ms, 1000ms – message is echoed back failed! Failed due to timeout.
    11845ms, 6003ms, 3ms – destroy succeeded!
    Running test 'test easyXDM.transport.BestAvailableTransport'
    Setup succeeded
    16875ms, 5000ms, 5000ms – onReady is fired failed! Failed due to timeout.
    17875ms, 6000ms, 1000ms – message is echoed back failed! Failed due to timeout.
    17876ms, 6001ms, 1ms – destroy succeeded!
    Running test 'test easyXDM.transport.BestAvailableTransport with query parameters'
    Setup succeeded
    22896ms, 5000ms, 5000ms – onReady is fired failed! Failed due to timeout.
    23897ms, 6001ms, 1000ms – message is echoed back failed! Failed due to timeout.
    23898ms, 6002ms, 1ms – destroy succeeded!
    Running test 'test easyXDM.Interface'
    Setup succeeded
    28925ms, 5001ms, 5001ms – onReady is fired failed! Failed due to timeout.
    29927ms, 6003ms, 1001ms – void method failed! Failed due to timeout.
    30928ms, 7004ms, 1001ms – async method failed! Failed due to timeout.
    31928ms, 8004ms, 1000ms – regular method failed! Failed due to timeout.
    31932ms, 8008ms, 2ms – destroy succeeded!
    Test run complete

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      I just tried it in the newest Chrome and can confirm that it crashes – the previous version did not.
      From what I can deduce its the hashprovider that causes it to crash when using the resize event instead of polling. Under normal use this will never occur as easyXDM will use the PostMessageTransport in Chrome and all other browsers that support this.
      But still, the library should not crash any browser – kinda funny how such simple code can do so :)

  • http://blog.dotnetwise.com/ DotNetWise

    Also safari for windows crashes, the big way!

    • http://kinsey.no/ Øyvind Sean Kinsey

      These are both based on the WebKit browser engine, so I was pretty much expecting that much..

  • http://blog.dotnetwise.com DotNetWise

    Also safari for windows crashes, the big way!

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      These are both based on the WebKit browser engine, so I was pretty much expecting that much..

  • http://blog.dotnetwise.com DotNetWise

    So what's the point of easyXDM if it would crash user's browser anyways?
    Is there any patch intended for chrome?

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      As previously stated, WebKit only crashes when running the HashTransport using onresize instead of polling – the usage of HashTransport over the preferred PostMessageTransport is forced to support the test.
      You can safely try the examples, like http://consumer.easyxdm.net/example/data.html as these will never use the HashTransport when running in WebKit (WebKit supports PostMessage).

      But yes, again as stated, the intention is for it to not crash in any case, so I'm going to take a look at this.

      Btw, there is actually a chance that it is the test framework itself that is crashing WebKit

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      As previously stated, WebKit only crashes when running the HashTransport using onresize instead of polling – the usage of HashTransport over the preferred PostMessageTransport is forced to support the test.
      You can safely try the examples, like http://consumer.easyxdm.net/example/data.html as these will never use the HashTransport when running in WebKit (WebKit supports PostMessage).

      But yes, again as stated, the intention is for it to not crash in any case, so I'm going to take a look at this.

      Btw, there is actually a chance that it is the test framework itself that is crashing WebKit

      • http://blog.dotnetwise.com DotNetWise

        Sounds Great :)

  • http://blog.dotnetwise.com/ DotNetWise

    So what's the point of easyXDM if it would crash user's browser anyways?
    Is there any patch intended for chrome?

    • http://kinsey.no/ Øyvind Sean Kinsey

      As previously stated, WebKit only crashes when running the HashTransport using onresize instead of polling – the usage of HashTransport over the preferred PostMessageTransport is forced to support the test.
      You can safely try the examples, like http://consumer.easyxdm.net/example/data.html as these will never use the HashTransport when running in WebKit (WebKit supports PostMessage).

      But yes, again as stated, the intention is for it to not crash in any case, so I'm going to take a look at this.

      Btw, there is actually a chance that it is the test framework itself that is crashing WebKit

    • http://kinsey.no/ Øyvind Sean Kinsey

      As previously stated, WebKit only crashes when running the HashTransport using onresize instead of polling – the usage of HashTransport over the preferred PostMessageTransport is forced to support the test.
      You can safely try the examples, like http://consumer.easyxdm.net/example/data.html as these will never use the HashTransport when running in WebKit (WebKit supports PostMessage).

      But yes, again as stated, the intention is for it to not crash in any case, so I'm going to take a look at this.

      Btw, there is actually a chance that it is the test framework itself that is crashing WebKit

      • http://blog.dotnetwise.com/ DotNetWise

        Sounds Great :)

  • http://blog.dotnetwise.com/ DotNetWise

    IE6 & IE7 Url is limited to 2048 characters, so are our messages!
    Actually even worse as they are uriEncoded.
    So we can't rely on hash method unleess the message is splited into chunks and sent over in different iterations.
    Do you think you can add this feature?

    Other browsers have bigger URL length limits, so we might want to pick the appropiate one for those known.

    Great stuff, btw!

    • http://kinsey.no/ Øyvind Sean Kinsey

      That is the url limit, the hash is not actually a part of this.
      I remember doing some tests, and I think I got quite a bit more than 2048.

      But I have been thinking about chunking, although it will create a bit of a overhead as the sending party will have to be notified about the message having been read, so that it can send the next one.

      For all my applications the size limit has not been a limit, but I guess I could take a look at this as well..

    • http://kinsey.no/ Øyvind Sean Kinsey

      The maximum lengt of the url might be 2048, but the maximum length of location.href is 4095.
      You can check this your self at http://easyxdm.net/hashlength.html
      Do NOT open this url in any browser except for IE6/7. This will cause it to loop for ever as Firefox etc has support for very long hrefs.

    • http://kinsey.no/ Øyvind Sean Kinsey

      The maximum lengt of the url might be 2048, but the maximum length of location.href is 4095.
      You can check this your self at http://easyxdm.net/hashlength.html
      Do NOT open this url in any browser except for IE6/7. This will cause it to loop for ever as Firefox etc has support for very long hrefs.

      • http://blog.dotnetwise.com/ DotNetWise

        4095 is correct, but is still "unpredictible" to rely on it unless when larger the messages to be splited in chunks. i.e I download some cross-domain clean text and some cross-domain html and both can have more than 20KB.
        And I don't want to use jsonP because the size would be even bigger because of nasty json encoding rules. + I would add some extra overhead to get the content from json!

        So when IE6/7 browsers are used and the uri encoded packed size is larger than 4096-main url length, it's better to have it splitted in chunks than just getting a quarter of your message, right?
        Otherwise there will be no extra overhead for browser that support postMessage and might be a 32KB / 64KB for other browsers just to make sure we are safe

        What do you think?

  • http://blog.dotnetwise.com DotNetWise

    IE6 & IE7 Url is limited to 2048 characters, so are our messages!
    Actually even worse as they are uriEncoded.
    So we can't rely on hash method unleess the message is splited into chunks and sent over in different iterations.
    Do you think you can add this feature?

    Other browsers have bigger URL length limits, so we might want to pick the appropiate one for those known.

    Great stuff, btw!

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      That is the url limit, the hash is not actually a part of this.
      I remember doing some tests, and I think I got quite a bit more than 2048.

      But I have been thinking about chunking, although it will create a bit of a overhead as the sending party will have to be notified about the message having been read, so that it can send the next one.

      For all my applications the size limit has not been a limit, but I guess I could take a look at this as well..

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      The maximum lengt of the url might be 2048, but the maximum length of location.href is 4095.
      You can check this your self at http://easyxdm.net/hashlength.html
      Do NOT open this url in any browser except for IE6/7. This will cause it to loop for ever as Firefox etc has support for very long hrefs.

    • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

      The maximum lengt of the url might be 2048, but the maximum length of location.href is 4095.
      You can check this your self at http://easyxdm.net/hashlength.html
      Do NOT open this url in any browser except for IE6/7. This will cause it to loop for ever as Firefox etc has support for very long hrefs.

      • http://blog.dotnetwise.com DotNetWise

        4095 is correct, but is still "unpredictible" to rely on it unless when larger the messages to be splited in chunks. i.e I download some cross-domain clean text and some cross-domain html and both can have more than 20KB.
        And I don't want to use jsonP because the size would be even bigger because of nasty json encoding rules. + I would add some extra overhead to get the content from json!

        So when IE6/7 browsers are used and the uri encoded packed size is larger than 4096-main url length, it's better to have it splitted in chunks than just getting a quarter of your message, right?
        Otherwise there will be no extra overhead for browser that support postMessage and might be a 32KB / 64KB for other browsers just to make sure we are safe

        What do you think?

  • Joe

    just like it~

  • Joe

    just like it~

  • http://kinsey.no/ Øyvind Sean Kinsey

    For those concerned about the size limit in IE6 and 7 due to the use of HashTransport – there is now a new fallback transport available, the NameTransport (http://easyxdm.net/docs/?class=easyXDM.transport….
    As far as I have seen, this can handle >150k messages :)
    Note that you need to supply a new parameter, remoteHelper for this to kick in!

  • http://oyvind.kinsey.no/ Øyvind Sean Kinsey

    For those concerned about the size limit in IE6 and 7 due to the use of HashTransport – there is now a new fallback transport available, the NameTransport (http://easyxdm.net/docs/?class=easyXDM.transport….
    As far as I have seen, this can handle >150k messages :)
    Note that you need to supply a new parameter, remoteHelper for this to kick in!

  • Pingback: Widget support added to easyXDM! | Rantings in the dark()

  • Hilary

    I'm also having the same issues in IE7 / XP and IE6 / XP.

    Thanks.

  • Pingback: link marketing()

  • Hilary

    I'm also having the same issues in IE7 / XP and IE6 / XP.

    Thanks.