JavaScript Debugging Techniques in IE 6

May 15 2009 by Ben Dowling | 46 Comments

Microsoft’s Internet Explorer 6 is almost universally hated by web developers. It’s hard to work with and support, but with a few solid techniques, you can make the process less painful. What “just works” in the majority of browsers will almost always require hours of tweaks and workarounds to get it working in IE6. With more and more users switching over to newer alternatives such as IE8, Safari and Firefox hopefully support for IE6 can be dropped sooner rather than later. In the mean time though many of us have to make sure our sites work in this awful browser.

JavaScript Debugging Techniques in IE 6

To make things worse, IE6 is extremely bad at helping developers diagnose problems. When a JavaScript error occurs, IE6′s default behaviour is to display a small error icon in the status bar. Extremely easy to miss!

Status Bar Error.

Double clicking on this icon will display a popup, and if you then click the “Show Details” button you’ll get the actual details of the JavaScript error. Unfortunately the detailed error message can be quite cryptic, and probably not too much help in diagnosing the actual problem. Your best bet is to make a note of the line and column number of the problem and then look that up in the source code. Fortunately, with the help of Visual Studio and by changing a few IE settings, we can make it much easier on ourselves.

Setting things up

To enable JavaScript debugging in IE we need to change some default settings, which can be accessed from the Tools> Internet Options menu, and then the Advanced tab. The image below shows the default IE6 settings, with the three settings we’re interested in highlighted.

Settings.

Script debugging in IE needs be enabled, which requires us to disable the first option out of the three. If you also want to debug scripts in other contexts (such as Outlook) then disable the second option. Enable the third option if you’d like the JavaScript error dialog to pop up automatically instead of being displayed as a small icon in the status bar.

Error Debugging.

After changing those settings and restarting IE, we’re ready to start debugging. All of the following examples show Visual Studio 2005, but the same applied to 2008. You can also use the free Web Developer Express Edition if you don’t own a full copy of Visual Studio. Instead of IE prompting you to open the debugger, as it does in the examples below, you’ll first need to create a project and then start the debugger yourself. From that point on everything is the same.

Basic debugging

Let’s start with a simple example. The code below tries to call a function that doesn’t exist:

<script type="text/JavaScript">
	functionDoesNotExist();
</script>

Now when we load that up into the browser instead of the tiny icon in the status bar IE will prompt us to open a debugger.

Select Debugger.

Selecting Visual Studio and clicking the yes button will open Visual Studio and highlight the code that is the cause of the problem.

Visual Studio.

For relatively simple errors, such as the one in the example above, just seeing the actual cause of the error highlighted is probably enough for us to work out what has gone wrong, and how to fix it. In more complex cases, however, we’ll need more information. This where the Visual Studio debugging features come in really handy.

In the code below we have a function, performAction, which takes a function as an argument and calls that function once it’s done. You’ll commonly see this sort of thing in JavaScript with asynchronous functions such as setTimeout and jQuery’s Get. There is a problem with the code below though: We’re accidentally passing in a string to performAction rather than a function.

<script type="text/JavaScript">
  /** 
   * Perform an imaginary action, and then
   * call the callback function once we're done
   */			
  function performAction(callback) {
  // Perform an action here
  // ...
  // We're done, call the callback 
     callback();
}
  // Call performAction with an anonymous 
  // callback function which contains an error
  var myFunc = "this is a string, not a function!";
  performAction(myFunc);
</script>

If we load up the code in IE and then debug it in Visual Studio as we have before we’ll see that the code “callback();” is highlighted, and is therefore the cause of problem. It won’t be obvious why this line is causing the problem though, not unless we know what the value of callback is. If callback was actually a function then there wouldn’t be a problem at all. The problem has only arisen because we accidentally passed in a string. This is where the “locals” window comes in handy. It lists all local variables along with their value and type. To display this window go to the Debug menu, then Windows, and then select Locals.

Debug Window.

With the locals window displayed it’s clear that the problem is that callback is a string, rather than a function. The locals window doesn’t just support basic types such as integers and strings. If you’ve got a local object you can look at all of its properties and see the value and type of each of them, as we’ll see in the next example.

Local Window.

The ‘debugger’ keyword

The ‘debugger’ keyword, also supported by the Firefox JavaScript debugger Firebug, can really help us to track down problems. Below is a slightly modified version of the previous example, where this time the callback function is passed an object that should include a status and message property. The message property has been misspelled though:

<script type="text/JavaScript">
  /** 
   * Perform an imaginary action, and then
   * call the callback function once we're done
   */			
  function performAction(callback) {
    // Perform an action here
    // ...
		
    // We're done, call the callback 
    callback({success: true, mesage: 'The action was performed!'});
  }

  // Call performAction with an anonymous 
  // callback function which contains an error
  performAction(function(response) {
    alert(response.message);
  });
</script>

Because ‘message’ has been misspelt as ‘mesage’ in the performAction function when we run this code in IE we’ll see a popup alert with the message “undefined”, rather than the actual message we were hoping to see.

Alert function.

In a large project it can be difficult to track down why a property we expect to exist is undefined. Instead of trawling through lots of code we can simply add the line “debugger;” above the alert statement. IE will then automatically prompt us to debug the code in Visual Studio when it hits that line. From the locals window we can see that the ‘message’ property has been misspelt.

Debugger statement.

Using the call stack window, which can be accessed in the same way we accessed the locals window, shown at the bottom right of the above screenshot we can work out exactly where this problem occurred. If we double click on the ‘performAction’ line, the previous statement in the call stack, we’ll see the source of the error.

Call stack.

While debugger statements can be a useful tool in helping you track down problems you should be careful not to leave them in your production code!

More advanced debugging

So far we’ve covered some basic examples, such as calling non-existent functions and undefined properties. Using the locals and call stack windows it was relatively straight forward to track these issues down. There are times when the techniques we’ve discussed so far can’t help though. We can’t see what global variables exist or what value they have with the locals window, for example, and the call stack doesn’t always handle remotely loaded or dynamically executed code very well.

For these situations we must turn to the immediate window. It is by far the most powerful debugging tool that Visual Studio has to offer, allowing us to evaluate JavaScript expressions on the fly.

The immediate window can be accessed in the same way that we accessed the other windows. Clicking inside the window will give it focus. We can then type JavaScript statements directly into the window and see the result. For example, type “window” followed by enter and you’ll get a print out of everything in the global scope.

Immediate Window.

When combined with the JavaScript arguments variable we can look in detail at all the current function arguments and the calling function. While the code in the next example isn’t something you’re likely to see in a real project, it does help to demonstrate techniques that can be extremely useful.

<script type="text/JavaScript">
  /** 
   * This function takes a variable number of arguments.
   */			
  function performAction() {
    // We're just interested in the immediate
    // window, start the debugger
    debugger;
  }

  // Call performAction with 4 different arguments, each of a different type
  performAction('argument 1', 2, {argument: 3}, function() { return 4; });
</script>

We’ll load this up into IE and then go straight to the immediate window once we’ve opened up the debugger. If we type “arguments” followed by enter we’ll see the following information displayed:

arguments
{...}
    [0]: "argument 1"
    [1]: 2
    [2]: {...}
    caller: null
    length: 4

The “{…}” tells us that arguments is an object. We also see this next to [2], so we know that the third argument (in array position 2) is an object. We can see what properties this object has by simply typing its name into the window:

arguments[2]
{...}
    argument: 3

The fourth argument wasn’t listed in the original output because it’s a function. We know it exists though because the length property tells us that there are 4 arguments. We can also confirm it is there using typeof:

typeof arguments[3]
"function"

Unfortunately the immediate window isn’t quite so helpful with functions as it is objects, and if we type in the name of the function we just see “{…}” rather than any details of the function itself. Fortunately there is a handy workaround. If we type “alert(arguments[3]);” then the function code will be displayed in an alert dialog:

Alert function.

Hopefully these examples have conveyed just how powerful the immediate window is.

Summary

With the help of Visual Studio it is possible to transform IE6 from obscure error messages into an effective debugger. By using the local and call stack windows we can quickly and easily track down the majority of problems. The debugger statement allows us to automatically jump into the debugger at any point in our code. Should we come up again a more complex where the other tools can’t help us then we can always turn to the immediate window, which allows us to execute arbitrary JavaScript to inspect the current environment.

About the Author

Ben Dowling is a passionate software developer who specializes in web and mobile application development. He currently works for Mendeley in London, UK, and regularly blogs about development at Coderholic

46 Comments

tim

May 15th, 2009

Thanks a lot for this article – really helpful. I’m having all sorts of problems with javascript in IE6 on a current project, so the timing for this article was great. ;)
thx again.

Gabe Harris

May 15th, 2009

You mean shoot yourself in the face isn’t the only option?

Bas

May 15th, 2009

This article is only 8 years too late… :) I’ve decided last year to stop IE6-support, that’s why my websites won’t work anymore with this almost ancient browser!

Jacob Gube

May 15th, 2009

@Gabe Harris: Apparently not! :)

@Bas: A lot of us can’t stop IE6 support because of our client base. This is true especially when you work for large multinational corporations and governmental agencies.

Joe Hoyle

May 15th, 2009

As a side note: As older browsers like IE6 are so bad with JS quirks I find it much easier to use jQuery for most Javascript ajax/effects etc as it has all the browser quirks ironed out, so when you use jQuery functions you know it will work in all browsers (well not all, but you get what I mean).

That being said, I guess depending on what you are trying to accomplish then a JS Library sometimes just don’t cut it.

Since using jQuery I have saved myself countless hours of debugging, I find Javascript bugs the most annoying, its like trying to get CSS to work in IE5 but even worse!

Ragini

May 15th, 2009

Awesome article!! I wud agree with what Jacob has said.. Many many of people out there are using IE 6.

BTW Visual Studio 5 is passe now.. I downloaded the free trial of Visual Studio Team System and is truly amazing.. Developers Delight.. U might want to try and review it- http://bit.ly/OxdIK

Jacob Gube

May 15th, 2009

@Joe Hoyle: jQuery and MooTools have kept me sane. Less JS browser quirks, and less code you have to write (and rewrite) in JavaScript. The problem isn’t only in browsers though, JS is just riddled with inconsistencies and it’s so long-winded; that’s why I appreciate languages like Ruby and Python. Couple jQuery/MooTools with Firebug and IE developer toolbar for IE testing, I think I’ve cut, at the very least, 30-40% of my development time simply by using them.

Benjamin Sterling

May 15th, 2009

I’ll save you all that work, get a copy of Opera 8, not 9, and you can debug IE6 easily using that. Same JS engine, better console.

Ryan Kearney

May 15th, 2009

http://getfirebug.com/lite.html

IE6 is 2 versions behind now what the fuck.

Coding for IE6 is like coding for Windows 2000.

Seriously wtf.

Tester

May 15th, 2009

But…Ruby and Python are not Javascript.

Why do people make such silly and worthless comparisons?

http://www.screambuy.com

May 15th, 2009

It is better to use higher version IE to avoid lost lost of bugs but have to face new bug .. haha

zac spitzer

May 15th, 2009

Any tips for working around the bug with line numbers being reported, but not the actual included affected javascript file?

Television SPy

May 16th, 2009

I love the web developer suite, it’s really good for editing js files.

Jacob Gube

May 16th, 2009

@Ryan Kearney: It’s not coding for, it’s supporting IE6.

Mauro

May 16th, 2009

The best way to get rid of this IE6 is to stop talking about it. Please!

Paul de Vries

May 16th, 2009

@Mauro, the thing is that alot of big company’s got computers with Windows 2000 on it, Windows 2000 is only supported by IE6, that is primary the reason why alot of people still use IE6, also as an addition; there are alot of people that bought a simple PC to surf and email. Those people wont even consider upgrading their browser because ‘it works’ for them and they block there self to be open for a new browser. (normally its because of the UI why they don’t switch)

So while we still have to consider IE6 its not a bad thing to discuss any improvements in the way we can debug IE6.

I personally have to be 100% sure it works in IE6 because most of my customers use IE6, pretty fked up thing is that also because of ‘security’ reasons they have flaws in their flash, etc. etc.

Gladly we have improvements like javascript frameworks that help us fight the obnoxious IE6.

Matt

May 16th, 2009

@Mauro: It’s not Tinker Bell. It doesn’t die if you stop believing in it.

Buguletzu

May 16th, 2009

@Matt: But if 90% of the population starts believing it, then it becomes a religion.

Michael Kozakewich

May 16th, 2009

“I do believe in IE6, I do, I do!”
It would make a good movie.

Pete

May 16th, 2009

Client is using IE6 right now. Can’t stand it. Had to have the latest version of the product we are installing, but can’t get an upgrade in for IE? WTF

john

May 17th, 2009

easier to just take care of all the obvious bugs with firefox tools and turn to google for the ie6 quirks (you’re going have to google it anyhow)

but i do appreciate the information

Tihomir Ivanov

May 17th, 2009

I couldn’t understand only: Why there are people that still uses this browser !?

wow homes

May 18th, 2009

Client is using IE6 right now. Can’t stand it. Had to have the latest version of the product we are installing, but can’t get an upgrade in for IE? WTF?

gus

May 18th, 2009

IE6 should NOT be supported by anyone, we should ALL deny access to grotesque IE6

Michael Riley

May 19th, 2009

I can’t remember what it’s called, but IE6 has the equivalent of FireBug for it, IMO it’s much more useful than visual studio could ever be.

Saloucious

May 19th, 2009

@Pete
Big companies are stucked with IE6 because they have validated theirs intranet applications with this browser.

An update to IE7 means to retest all theirs apps (very expansive) …

Daniel15

May 19th, 2009

Get IETester from http://www.my-debugbar.com/wiki/IETester/HomePage, then you can test IE5.5, IE6, IE7 and IE8 all at once :)

Although, a lot of people aren’t supporting IE6 any more. It’s holding the intenet back :(

Daniel15

May 19th, 2009

I meant that IE6 is holding the web back, not the people that aren’t supporting it. I fully support those people. :P

mihai

May 19th, 2009

Nice article. Too bad that for debugging JS in IE6 you need another MS program.
But for large JS applications, it’s a bliss to know where the error comes from.

Jacob Gube

May 19th, 2009

@Daniel15: Thanks, we need all the support we can get. It’s just frustrating sometimes when you can’t do something creative or elaborate because you already know there’s no chance it’s going to work in IE(6). One thing is PNG alpha transparencies; you can get away with PNGFix or a similar JS library, but then you get stuck with a non-degrading web page that relies on JS to do what should really be styling (CSS).

I find that there are two types of developers: those that have real-world demands (clients needing IE6 support, deadlines, administrative BS), and those that can criticize those developers because they’re just starting out or because it’s just a hobby for them. As much as I’d like to work for people who would just like to support Firefox, it’s not gonna happen; not in the real-world, not in the big, corporate level. I hate finger-pointing, and I’m not one to cast blame, but if I were to do so, it’s not developers suporting IE, but rather people in charge of Information Technology systems who can’t/won’t upgrade their IT infrastructure.

Cat

May 19th, 2009

Good article.
Lots of companies are ditching Firefox in favor of IE lately. It surely helps having these debugging techniques.

Good job.

Ryan Kearney

May 20th, 2009

@Jacob Gube
I understand that, but why would you support users that are 2 versions behind with a web browser?
I’m an application developer, and I don’t support Windows 2000 anymore.

Jacob Gube

May 20th, 2009

@Ryan Kearney: Me personally? I have worked in building distance-learning education for some governmental agencies. Many of their computers are still ME/XP with IE6. They are the primary audience, and thus, distance-learning courseware must be IE6 compliant.

Same goes for corporate training sites. Many users, who use computers issued to them by the company, still have IE6 / XP. I’m not going to reveal specifics, but I know of at least one major multinational company who still has Windows 2000 + IE6 for most of their corporate executives.

slajax

May 20th, 2009

Unfortunately, due to the amount of XP systems sold, the distance between upgrades and the resistance to the vista upgrade paths, I think we’ll still be seeing quiet a bit of IE6 for the next few years. At least until IE8 ships as a windows update patch.

Vincent Voyer

May 25th, 2009

alert(‘download firefox’); is enough for me

timekeeping software

July 2nd, 2009

How is this relevant when IE6 has minimum market share which will only getting worse? Forget the IE6 users.

LepeKaname

August 18th, 2009

I think as developers we have the power to turn off IE$. If we can set a “basic” layout/design for IE and advanced one for the rest, we cab do the trick. For example: Just add a button to switch to “advanced” mode and alert IE users that for them, could be buggy, and suggest to use any other browser instead. That way, IE users will still have functionality but with less features.

I don’t want to keep spending hours Hacking my codes to pleasure IE browsers that care very little about standards.

Mike Palmer

November 3rd, 2009

I agree with Jacob, people who don’t develop web applications for a living are free to utter the “Just stop supporting IE6″ battle-cry, while the rest of us poor souls who have paying clients have to conform to specs like “support IE6″ or “I want a flashing ticker”.

Let’s face reality and continue to support IE6 (here in Asia, you’re looking at up to 50% of traffic still using IE6!) whilst pushing standards. Also, with the uptake of Windows 7, the time line for IE6 to become obsolete is getting shorter.

John

December 15th, 2009

“Coding for IE6 is like coding for Windows 2000.”

Tell that to our corporate clients who are still using IE6 and there Tech guys refuse or will not allow them to upgrade, thats the major problem with IE6, your average home user has probably upgraded many moons ago, but its when you do work for large companies or organisations you tend to find they still use IE6 and there Tech guys have no plans in the not so distant future to upgrade there browsers.

Tech guys pull your fingers out and upgrade

Smita

March 17th, 2010

hi,
I m nt able to get popup which says “Do u want to debug now?”

Neil

August 17th, 2010

Thank you for this article – you are a life saver!!

William Li

August 19th, 2010

Client: “We are not asking much, can’t you just make our site work 100% the same across IE6 7 and 8, it is only just one browser that we ask you to support here, you can ignore Safari, Firefox for now.. and yet you failed to make all the fields line up and the png load up really slowly on IE6…”

B Dubs

November 21st, 2010

I was going to rant and bitch about ie6, but it’s hopeless.

Thanks for the article.

Nosy Rat

December 15th, 2010

Very helpful.

May IE6 be sent to the bermuda triangle.

Thanks.

jyapucha

June 17th, 2013

try using a tool called Fiddler or IE dev tools

Val

December 8th, 2013

Once IE6 was a breakthrough, but years gave passed and it finally have died. But we will always remember it.

Leave a Comment

Subscribe to the comments on this article.