Firefox firebug and synchronos calls problem
April 12th, 2007 by lukavFor 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) {
OAT.AJAX.response(xhr);
}
} 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.AJAX.response(xhr);
}
}
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 »
April 19th, 2007 at 21:15
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.
June 5th, 2007 at 15:30
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.
June 5th, 2007 at 15:40
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.
June 5th, 2007 at 17:38
https://bugzilla.mozilla.org/show_bug.cgi?id=383304
November 21st, 2007 at 00:44
Can you explain how exactly this code should be implemented? Here is my code:
xmlhttp.open(‘GET’,getQuery, false);
xmlhttp.onreadystatechange=state_Change;
xmlhttp.send(null);
Where should the code you posted go?
Thanks,
Phil
November 21st, 2007 at 10:07
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:
xmlhttp.open(’GET’,getQuery, false);
xmlhttp.onreadystatechange=state_Change;
xmlhttp.send(null);
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.
November 21st, 2007 at 20:56
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.
November 22nd, 2007 at 08:21
Phil,
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.
December 17th, 2007 at 22:45
Thank you very much! This bug was killing me
March 5th, 2008 at 00:04
yeah thanks a tons that bug was being a pain in the butt
March 20th, 2008 at 19:09
lukav,
after days of unsuccesful search on the web, finally i found the solution on your one.
xmlhttp.open(’GET’,getQuery, false);
xmlhttp.onreadystatechange=state_Change;
xmlhttp.send(null);
if (xmlhttp.onreadystatechange == null) state_Change();
It’s resolve all my problems with XMLHttp on mozilla’s browser!
Thank a lot
Bye
Federico
April 18th, 2008 at 18:27
Awesome. Have been working with this bug for ages now.
This line works great:
if (xmlhttp.onreadystatechange == null) state_Change();
thanks!
May 9th, 2008 at 04:14
Gracias muchas muchas GRACIAS
May 14th, 2008 at 22:19
The line:
if (xmlhttp.onreadystatechange == null) state_Change();
fixed the firefox problem. But it broke Internet Explorer. What to do???
Thanks
May 15th, 2008 at 00:20
Execute the line only if the browser is IE. There are plenty of samples how to detect the browser 🙂
July 15th, 2008 at 11:59
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……..
July 21st, 2008 at 13:32
firefox no onreadystatechange method?
yes?
July 21st, 2008 at 14:27
Handan,
what is your question?
July 26th, 2008 at 23:54
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
July 27th, 2008 at 11:25
[…] zu sein. Das Problem tritt im
September 2nd, 2008 at 08:53
Marcel,
try { if(browser.mozilla && !this.async && self.xmlhttp.onreadystatechange==null) this.ready();
}catch(e){this.ready()}
is the ready() userdefined method? whats the this object??
October 29th, 2008 at 17:21
Thanks for that,
This issue has been a concern for me for a while – nice to see someone has shared the answer.
-Ross
November 8th, 2008 at 01:31
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!!!
November 25th, 2008 at 18:56
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.
February 10th, 2009 at 01:08
Thank you VERY much! That did it! Been scratching my head with this one for a long time …
March 19th, 2009 at 23:56
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.
April 29th, 2009 at 09:45
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?
April 29th, 2009 at 10:07
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.
May 5th, 2009 at 04:37
Love you men! Saved my life!
July 6th, 2009 at 10:08
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!
July 31st, 2009 at 19:12
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.
February 3rd, 2014 at 15:51
[…] Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem. […]