As promised (over in TPD, but hey, that's where the action is) I shall now provide detailed instructions on how to use Microsoft® Visual Web Developer™ 2008 Express Edition for debugging JavaScript in Internet Explorer 
As one might expect from a MS product, this involves changing fundamental aspects of the configuration of the operating system which will affect all of your future usage of the system, so I shall also explain how to get things back to "normal" (===broken in the way you're used to) afterwards.
Oh, and this is on XP, but AFAIK it's identical on Vista.
OK, let's get started
Step 1: System Configuration
If you're not using that instance of IE for anything else, you can close it - it's of no further relevance, for reasons that will become apparent
OK, done that? Time for...
Step 2: Application Configuration
Step 3: Using the Damn Thing
You should now (or in a minute or so, once MSVWD2008EE has had time to ponder the state of the Universe - like most Microsoft products, it behaves like an early beta of Marvin the Paranoid Android, often pausing in the middle of a task and shaking its head despondently for no apparent reason) - anyway, by now there should be a toolbar immediately above the place where the editor would be if you had anything to edit, containing a green rightwards pointing arrowhead (your right: > like that, but a solid green triangle). Click that and a dialog will appear complaining about some irrelevant bulltulip or other. Just select the option of creating a "Web.Config" file (I'm not sure if it's all that important as this only affects the server side of ASP.NET, but knowing MS's incompetence they've allowed the boundaries to leak) and if you wait a while, a new Internet Explorer window will automagically open, showing a default ASP.NET view of a directory containing only said Web.Config file.
Rather disappointing after all that effort, isn't it.
However... if you now go to the location bar and enter the appropriate URL, such as http://example.com/cool_page_with_js_bugs.html then the first JavaScript error encountered will drop you into the debugger at the point of FAIL, and then you can get into all the usual debugging techniques... examine variables in the current scope, use the "watch" frame to examine stuff, use the call stack to walk back up and see what the values of the variables in scope up there were, set breakpoints at likely places where the FAIL originates (then hit the green triangle "run" button again, return to the browser, reload the page and you'll hit the breakpoints)... the code is your oyster
And when you're no longer debugging and don't want to put up with the (truly shocking) number of JS errors thrown up by the sites you visit every day, all you have to do is reverse step 1:
Step 4: Back to Living with The Broken-By-Incompetent-Fools Web
And there you are. HTH, HAND, YMMV, TTFN
P.S. If you have an already-loaded page and want to get into the debugger just for the sake of examining some variables or setting a breakpoint, type javascript:debugger into the location bar. If you know whereabouts in your code you want to drop into the debugger, you can enter
debugger;
as a statement in the source file containing the script, but you must remember to remove it before you deploy the code, as otherwise it will be seen as an error by non-debugger-aware browsers of various ilks.
It must be an instance of IE started from within MSVWD2008EE for either of those techniques to work - IE itself doesn't know how to start the debugger.
On Firefox, use the Firebug extension - that understands the debugger statement.
As one might expect from a MS product, this involves changing fundamental aspects of the configuration of the operating system which will affect all of your future usage of the system, so I shall also explain how to get things back to "normal" (===broken in the way you're used to) afterwards.
Oh, and this is on XP, but AFAIK it's identical on Vista.
OK, let's get started
Step 1: System Configuration
- If you don't have IE running, fire it up
- On IE's "Tools" menu, select the "Internet Options..." menu item (there's an alternative route via Control Panel > Internet, if you so wish)
- Select the tab labelled "Advanced" (far right)
- In the second branch of options, headed "Browsing", UNCHECK "Disable script debugging (IE only)" and CHECK "Show a notification on every script error" (this is the opposite of the default configuration, but just in case something has changed the defaults on your system, simply make sure that the first is unchecked, and the second is checked).
- "OK" your way out of the dialog.
If you're not using that instance of IE for anything else, you can close it - it's of no further relevance, for reasons that will become apparent
OK, done that? Time for...
Step 2: Application Configuration
- If it's not already running, fire up Microsoft® Visual Web Developer™ 2008 Express Edition (MSVWD2008EE for short
) - Once it's managed to get its head around the arduous business of starting up and phoning home, hit the "File" menu and select the "New web site..." menu item
- The dialog box that now appears will have the "New ASP.NET Web Site" option selected, and will want to put the new project in a directory tree under your current username's "My Documents" directory (just "Documents" on Vista, IIRC). You can just use the defaults, or do what I do and select the "Empty web site" option - but even then you might as well leave it in the default location, as it's ultimately irrelevant where it lives. You might also want to change its name from "Project1" to something else ("WTF - I only want to use the JS debugger" is one possibility
) although I tend to just leave it as it is - saves keystrokes - You don't have to do this every time - next time you fire up MSVWD2008EE for a debugging session, simply re-open this project. You never actually do anything with this project, it's just used to hook the debugger into the IE process.
- Cheer up, we're nearly there
Step 3: Using the Damn Thing
You should now (or in a minute or so, once MSVWD2008EE has had time to ponder the state of the Universe - like most Microsoft products, it behaves like an early beta of Marvin the Paranoid Android, often pausing in the middle of a task and shaking its head despondently for no apparent reason) - anyway, by now there should be a toolbar immediately above the place where the editor would be if you had anything to edit, containing a green rightwards pointing arrowhead (your right: > like that, but a solid green triangle). Click that and a dialog will appear complaining about some irrelevant bulltulip or other. Just select the option of creating a "Web.Config" file (I'm not sure if it's all that important as this only affects the server side of ASP.NET, but knowing MS's incompetence they've allowed the boundaries to leak) and if you wait a while, a new Internet Explorer window will automagically open, showing a default ASP.NET view of a directory containing only said Web.Config file.
Rather disappointing after all that effort, isn't it.
However... if you now go to the location bar and enter the appropriate URL, such as http://example.com/cool_page_with_js_bugs.html then the first JavaScript error encountered will drop you into the debugger at the point of FAIL, and then you can get into all the usual debugging techniques... examine variables in the current scope, use the "watch" frame to examine stuff, use the call stack to walk back up and see what the values of the variables in scope up there were, set breakpoints at likely places where the FAIL originates (then hit the green triangle "run" button again, return to the browser, reload the page and you'll hit the breakpoints)... the code is your oyster
And when you're no longer debugging and don't want to put up with the (truly shocking) number of JS errors thrown up by the sites you visit every day, all you have to do is reverse step 1:
Step 4: Back to Living with The Broken-By-Incompetent-Fools Web
- On IE's "Tools" menu, select the "Internet Options..." menu item (there's an alternative route via Control Panel > Internet, if you so wish)
- Select the tab labelled "Advanced" (far right)
- In the second branch of options, headed "Browsing", CHECK "Disable script debugging (IE only)" and UNCHECK "Show a notification on every script error" (this is the default configuration).
- "OK" your way out of the dialog.
And there you are. HTH, HAND, YMMV, TTFN
P.S. If you have an already-loaded page and want to get into the debugger just for the sake of examining some variables or setting a breakpoint, type javascript:debugger into the location bar. If you know whereabouts in your code you want to drop into the debugger, you can enter
debugger;
as a statement in the source file containing the script, but you must remember to remove it before you deploy the code, as otherwise it will be seen as an error by non-debugger-aware browsers of various ilks.
It must be an instance of IE started from within MSVWD2008EE for either of those techniques to work - IE itself doesn't know how to start the debugger.
On Firefox, use the Firebug extension - that understands the debugger statement.
Comment