Favourite Projects



Firefox firebug and synchronos calls problem

April 12th, 2007 by lukav

For those of you that have discovered that when you have Firebug installed and are developing some synchronous XMLHttpRequest everything works, and when you disable it it stops: here is the problem.

Believe it or not it is a bug in Firefox NOT in Firebug. It turns out that Firefox doesn’t call onreadystatechange when the you set the 3 parameter (async) to false in open. Probably FF expects that when a call is synchronous the developer will process the result in the lines following the send call. May be this make sense, but if you want to quickly test async/sync calls or use a library that doesn’t take care of this, you be in trouble.

I can say for certain (I’ve committed the code myself) that the next release of OpenLink AJAX Toolkit won’t have this problem and will make no difference if you have Firebug or not.

I use the following to catch the situation where Firebug is not installed or is installed but disabled:

if (OAT.Browser.isGecko)
  try {
    if (!xhr.options.async && xhr.obj.onreadystatechange == null) {
  } catch (e) {
    if ((e.message && e.message == 'Permission denied to create wrapper for object of class UnnamedClass') ||
         e == 'Permission denied to create wrapper for object of class UnnamedClass')

OAT.Dom.isGecko() – return true if it mozilla and derivatives
OAT.AJAX.response – is the function that is normally called when the request finish.
xhr.options.async – is holding if the call is async or not
xhr.obj.onreadystatechange – is the original Firefox XMLHttpRequest object instance, since the code above works in the context of OAT

Posted in EN, OAT, OpenLink, Tech | 32 Comments »

32 Responses

  1. A Casa do Java Says:

    Great! I had to use the workaround “process the result in the lines following the send call” cause my syncronous call didn’t work in Firefox 1.5. However, it works all the way in Firefox 2.0 and, of course, IE 6 and 7.

  2. Chris Bloom Says:

    Thanks for the solution! This was bugging me all weekend. So is this a bug in Mozilla? If so, I couldn’t find any bug report related to it in Bugzilla.

  3. lukav Says:

    My pleasure,

    Yes it is a bug in mozilla IMO, I’ve recently read some specs where is was explicitly stated that onreadystatechange should be called with sync calls also. But I have to admit that I haven’t checked the bugzilla.

  4. Chris Bloom Says:

  5. Phil Says:

    Can you explain how exactly this code should be implemented? Here is my code:‘GET’,getQuery, false);

    Where should the code you posted go?


  6. lukav Says:

    Hi Phil,

    the code I posted is for OAT. And it is long included in the distribution. So in your case, since you don’t use OAT you should call the procedure by yourself like so:’GET’,getQuery, false);
    if (xmlhttp.onreadystatechange == null) state_Change();

    I think this should do the trick, so you don’t have problems with you app if Firebug is installed or not.

  7. Phil Says:

    Thanks Lukav — it’s firing now but I can’t seem to do anything with the xmlhttp.responseText that is returned. For example, take the returned XML and parse it.

  8. lukav Says:

    What do you mean?
    Is xmlhttp.responseText empty after the call? Can you provide an example?
    If your are using windows I recommend using ‘fiddler’ so you can see the actual http request- response, just to make sure a content is returned.
    I also recommend using some library like OAT or OpenAjax, since the browser incompatibilities are taken care of and you don’t need to reinvent the wheel all the time.

  9. Fellipe Cicconi Says:

    Thank you very much! This bug was killing me

  10. ben Says:

    yeah thanks a tons that bug was being a pain in the butt

  11. Federico Says:

    after days of unsuccesful search on the web, finally i found the solution on your one.’GET’,getQuery, false);
    if (xmlhttp.onreadystatechange == null) state_Change();

    It’s resolve all my problems with XMLHttp on mozilla’s browser!

    Thank a lot

  12. ScratchMyTail Says:

    Awesome. Have been working with this bug for ages now.
    This line works great:
    if (xmlhttp.onreadystatechange == null) state_Change();


  13. Alex from Chile Says:

    Gracias muchas muchas GRACIAS

  14. Jeremy Says:

    The line:
    if (xmlhttp.onreadystatechange == null) state_Change();

    fixed the firefox problem. But it broke Internet Explorer. What to do???


  15. lukav Says:

    Execute the line only if the browser is IE. There are plenty of samples how to detect the browser 🙂

  16. pradeep Says:

    Thanks Federico…
    We found this problem in our application…
    We got rid of this problem by using this single line of code..
    Thanks once again……..

  17. handan Says:

    firefox no onreadystatechange method?

  18. lukav Says:

    what is your question?

  19. marcel Says:

    Mozilla 3 for windows has fized this bug. But with firebug, and this bugfix, u will get the error “Permission denied to create wrapper for object of class UnnamedClass” when u call the xmlhttp ready() after send().

    to “fix the bugfix” u shd inlude the bugfix in a try block and put the ready() call in catch block, otherwise it will not work in mozilla 3 with firebug console enabled.

    in my code i have:
    try { if(browser.mozilla && !this.async && self.xmlhttp.onreadystatechange==null) this.ready();
    }catch(e){this.ready()}//fix mozilla 2 bug

  20. Synchroner XMLHttpRequest und Firefox reagiert nicht mehr - XHTMLforum Says:

    […] zu sein. Das Problem tritt im

  21. aj Says:

    try { if(browser.mozilla && !this.async && self.xmlhttp.onreadystatechange==null) this.ready();

    is the ready() userdefined method? whats the this object??

  22. Ross Says:

    Thanks for that,

    This issue has been a concern for me for a while – nice to see someone has shared the answer.


  23. Robert Says:

    Thank you so very very much for the solution. Been banging my head against a wall looking for the reason why this was not working in FF. All the best to you in the future!!!

  24. lukav Says:

    Marcel suggestion needs a little extension in order for the new Firebug to work.
    So I have updated my example in the post to work with FF3, FF2 and FB1.0, FB1.2.

  25. Pedro Doria Says:

    Thank you VERY much! That did it! Been scratching my head with this one for a long time …

  26. Jukko Says:

    and more laconic version:

    var run = true;
    try { run = (!!xhr && !xhr.onreadystatechange; } catch (e) { }
    if (run) onStateChange();

    this is an example which is not required to check the exception message.

  27. Joe Says:

    I think that I’m having this issue with jQuery. I have code that will not function unless FireBug is installed and active. How would I integrate the fix in this case?

  28. lukav Says:

    I guess that in this case you should patch jQuery. However I have never used it and can not tell what the patch would be.

    You should look into the jQuery function you are calling to make a request and find how would they instantiate the xmlhttp.

    Another possibility is post in the jQuery developer forums with details about your problem and a fix request. You can reference my page and make a simple page that shows the problem. The jQuery developers would make this patch much faster.

  29. Javier Says:

    Love you men! Saved my life!

  30. Vasile Ceteras Says:

    I’ve had this issue with firefox 3.0.11 too. My synchronous ajax call was working fine in all browsers but FFOX.
    Thank you for the solution!

  31. Vidar S. Ramdal Says:

    Thanks sooo much for posting this!

    FYI, the latest Firebug (1.4.1) no longer alters Firefox’s behavior, so now Firefox ignores onreadystatechange for synchronous requests, even if Firebug is running.

  32. Why, Blog, Why?! | A note about synchronous xmlhttp requests and Firefox Says:

    […] Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem. […]

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.