Browsers for Debugging

You've got a small issue in your JavaScript. Sticking a simple alert() or console.log() into the code will probably tell you what you need to know. Of course, Murphy's Law says that you want to look inside a long-running loop. Which browser will help you out? Which will bite you?

Opera

With an alert() open, you look, you see the issue. You edit the source. Problem fixed (you hope).

Your page has been patiently waiting at the alert(). You press F5 to reload. You are back in business.

This couldn't be friendlier. (At least until they write a browser that can fix bugs for you.)

If worst comes to worst, if you are looking at an alert() you can click the "X" that stops loading. This terminates the running code, including that modal box. Life is good.

Firefox

If you regularly develop with Firebug, Firefox is your friend. If you haven't got Firebug running, it's still almost as good as Opera. Again, you can leave an alert() waiting while you edit your source. Again, reloading the page kills the open alert() and life is good.

There is, however, no way to click "stop loading" with an open alert(). You can, however, close the tab with an open alert. Brute force? Yes. Inconvenient? Not really. Press Ctrl+O and the default is to reopen the tab you just killed. It's about a keystroke behind Opera.

Chrome

Sorry to say, Chrome is not your friend in this situation. I hope you've taken the time to learn its developers' environment. If not, you cannot do anything while a modal dialog is waiting for you. You have to click "OK" or otherwise dismiss the alert(). If it's in a loop, you get another alert() before you get a chance to terminate the page load.

On the bright side, after a couple of unwanted alert() boxes, your modal dialog suddenly adds a checkbox asking, "Prevent this page from creating additional dialogs?" Your choice (yes, of course) is not retained after you reload the page. So you accept this escape, edit and reload. Or you accept this escape and continue debugging with another browser.

MSIE

How can they keep doing this? You'd think the geeks in Redmond would be fed up with their own browser. The only reason I can think of is that they never make mistakes, so they never stick in an alert(). Ask me if I believe that?

You cannot stop loading with a modal alert() showing. You cannot close the tab with a modal alert() showing. You cannot close MSIE with an alert() showing. Your one choice: Ctrl+Alt+Del.

As a practical matter, you never drop an alert() into your code if you are debugging with MSIE. (Why would you ever debug with MSIE? Oh. Right. The bug only shows up in MSIE, so you can't use any other browser.) What do you do?

The built-in debugging tools in MSIE are not bad, but you can't get to them with a modal alert() showing. So instead of an alert(), drop a throw statement into your code. That will trigger an error. The error will get you into the debugger. The debugger will show you those vars that you need to look at to see what went wrong.

The big downside to the MSIE built-in debugging is that it totally gives up on anonymous functions. If you're past the beginner stage, you typically build your UI with anonymous functions, often members of an object. If you need a traceback for your debugging, MSIE will leave you out in the cold. So drop in that throw statement to trigger an error. But run the program in Opera with the Error Console open. That gives you an excellent traceback. Then run your code in MSIE, and use the Opera Error Console for the traceback you'll need.

And that, dear friend, is not a process you can hurry along by venting. If there are others within earshot, try to express your opinions in language that is appropriate for a working professional, whatever you may feel. Your coworkers will appreciate it.

Feedback: MartinRinehart at gmail dot com

# # #