Firebug Tip - When Ajax Calls Go Bad...

This post is more than 2 years old.

Soon to be a new Fox special - this is something that's been bugging me for quite some time. I use Firebug every single day, but I've noticed that it doesn't really keep a history of events. Why do I need a history? I've noticed that in some situations, if my code does an Ajax call to foo.cfm, and foo.cfm throws a ColdFusion exception, then the browser may go to a new page. So for example, imagine this link:

<a href="" onclick="doFoo();return false">Do It</a>

Normally this works fine, but if doFoo screws up, the browser 'misses' the return false and can send you to a new page. This makes debugging difficult sometimes. So for example, if doFoo did an Ajax request, I'd actually see the red response in Firebug for a split second before the browser went to the new URL. Firebug would then lose the data as it's in a new request.

The browser error console keeps a history, but what I really need is the response from the Ajax call in Firebug. If I have that, I can look at what ColdFusion returned and see the error.

Ok, so it turns out there is a way to deal with this. If you open up Firebug, click on Script, and then go to Options, there is a "Break on All Errors" option. It took me a while to find this because there are multiple options link on the page. I've made it obvious here:

Once you activate this, any error will cause the browser to stop. You can then click on the Net tab to examine the XHR request and see the response.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Rick Mason posted on 6/12/2008 at 8:36 PM

Superb, thank you.

Comment 2 by Scott Bennett posted on 6/12/2008 at 8:41 PM

Ray,

That's cool, I never even noticed that options menu. I was looking on my firebug and I noticed that you have 2 more options then I do.

http://www.coldfusionguy.co...

I was particularly interested in the "Show Chrome Sources" option as I've been thinking about having my Wii chromed like this:

http://gizmodo.com/gadgets/...

=D

Comment 3 by Raymond Camden posted on 6/12/2008 at 8:47 PM

Scott - I'm running a 1.2 beta.

Comment 4 by Michael Brennan-White posted on 6/12/2008 at 8:49 PM

good to Know.

Does anybody have a copy of the latest Firebug xpi? GetFirebug.com has been down for 3 days now and the version I have of FB bombs when I try to do jQuery mods in the console.

Comment 5 by Robert Gatti posted on 6/12/2008 at 9:23 PM

Awsome! This is a great find...up until now I've just gotten really quick on escape key to stop the browser from actually going to the new page.

Comment 6 by Joe posted on 6/12/2008 at 10:41 PM

Ray,

Why not just put onclick="return doFoo();" and make sure doFoo has a try/catch that returns false on error, and true when completing successfully?

Comment 7 by Joe posted on 6/12/2008 at 10:43 PM

Oops that might not work, but there are ways to just make sure the function traps the error and offers another way to the desired result without having to stop the page from changing after the error.

Comment 8 by Raymond Camden posted on 6/12/2008 at 10:45 PM

That assumes I'm going to know what is going to fail. ;) Yea, that would work - but I'll be doing this mainly and I'm just happy I finally figured it out. :)

Comment 9 by Tom posted on 6/13/2008 at 1:05 AM

Brilliant, thanks for posting that!

Comment 10 by Daniel D posted on 6/13/2008 at 2:38 AM

Instead of using ";false" in the event def you use event.preventDefault(). Though you probably want something like JQuery or other framework/code that give proper cross browser event object support IE has it own way of doing things. event.preventDefualt() as the name suggests prevents the default action on what ever item the event triggered on. Very handy prevents forms from submitting links from being followed. And can be controlled in any of the event handler(s) if there are multiple (or events that bubbled up).

Comment 11 by Raymond Camden posted on 6/13/2008 at 5:18 AM

preventDefault... wow. It amazes what kind of stuff you can find in the DOM. One of the conferences needs to hold a JavaScript class. Not a "101" style per se but more a "Did you know you could..." type class.

Comment 12 by Troy Allen posted on 6/13/2008 at 5:30 PM

If you use preventDefault and stopPropagation together, that should cover almost all browsers out there right now (including IE):

event.stopPropagation();
event.preventDefault();

Comment 13 by Ryan Gahl posted on 6/13/2008 at 7:58 PM

Hi Raymond. Sorry if this comes across as somewhat of a plug, but I came across your post here, and noticed in your last comment that you are potentially looking for some sort intermediate to advanced javascript/ajax training. I just wanted to let you know that we're here :)

We have been doing javascript and Ajax development as our primary development (and source of income) for a while now, and have run into lots of gotchas and have solved a lot of problems. Just an FYI if you're interested. It's not on our website (www.nthpenguin.com), but we can put together some custom training if that's something you might benefit from.

Keep up the learning and the blogging :) - and again my apologies if you view this in any way shape or form as comment spam... just thought we might be able to help.