Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When I find that I have a problematic code snippet, how should I go about debugging it?
Firebug is one of the most popular tools for this purpose.
All modern browsers come with some form of a built-in JavaScript debugging application. The details of these will be covered on the relevant technologies web pages. My personal preference for debugging JavaScript is Firebug in Firefox. I'm not saying Firebug is better than any other; it depends on your personal preference and you should probably test your site in all browsers anyway (my personal first choice is always Firebug).
I'll cover some of the high-level solutions below, using Firebug as an example:
Firefox
Firefox comes with with its own inbuilt JavaScript debugging tool, but I would recommend you install the Firebug add on. This provides several additional features based on the basic version that are handy. I'm going to only talk about Firebug here.
Once Firebug is installed you can access it like below:
Firstly if you right click on any element you can Inspect Element with Firebug:
Clicking this will open up the Firebug pane at the bottom of the browser:
Firebug provides several features but the one we're interested in is the script tab. Clicking the script tab opens this window:
Obviously, to debug you need to click reload:
You can now add breakpoints by clicking the line to the left of the piece of JavaScript code you want to add the breakpoint to:
When your breakpoint is hit, it will look like below:
You can also add watch variables and generally do everything that you would expect in a modern debugging tool.
For more information on the various options offered in Firebug, check out the Firebug FAQ.
Chrome
Chrome also has its own in built JavaScript debugging option, which works in a very similar way, right click, inspect element, etc.. Have a look at Chrome Developer Tools. I generally find the stack traces in Chrome better than Firebug.
Internet Explorer
If you're developing in .NET and using Visual Studio using the web development environment you can debug JavaScript code directly by placing breakpoints, etc. Your JavaScript code looks exactly the same as if you were debugging your C# or VB.NET code.
If you don't have this, Internet Explorer also provides all of the tools shown above. Annoyingly, instead of having the right click inspect element features of Chrome or Firefox, you access the developer tools by pressing F12. This question covers most of the points.
Internet Explorer 8 (Developer Tools - F12). Anything else is second rate in Internet Explorer land
Firefox and Firebug. Hit F12 to display.
Safari (Show Menu Bar, Preferences -> Advanced -> Show Develop menu bar)
Google Chrome JavaScript Console (F12 or (Ctrl + Shift + J)). Mostly the same browser as Safari, but Safari is better IMHO.
Opera (Tools -> Advanced -> Developer Tools)
There is a debugger keyword in JavaScript to debug the JavaScript code. Put debugger; snippet in your JavaScript code. It will automatically start debugging the JavaScript code at that point.
For example:
Suppose this is your test.js file
function func(){
//Some stuff
debugger; //Debugging is automatically started from here
//Some stuff
}
func();
When the browser runs the web page in developer option with enabled debugger, then it automatically starts debugging from the debugger; point.
There should be opened the developer window the browser.
I use old good printf approach (an ancient technique which will work well in any time).
Look to magic %o:
console.log("this is %o, event is %o, host is %s", this, e, location.host);
%o dump clickable and deep-browsable, pretty-printed content of JS object. %s was shown just for a record.
And this:
console.log("%s", new Error().stack);
gives you Java-like stack trace to point of new Error() invocation (including path to file and line number!!).
Both %o and new Error().stack available in Chrome and Firefox.
With such powerful tools you make assumption whats going wrong in your JS, put debug output (don't forget wrap in if statement to reduce amount of data) and verify your assumption. Fix issue or make new assumption or put more debug output to bit problem.
Also for stack traces use:
console.trace();
as say Console
Happy hacking!
Start with Firebug and IE Debugger.
Be careful with debuggers in JavaScript though. Every once in a while they will affect the environment just enough to cause some of the errors you are trying to debug.
Examples:
For Internet Explorer, it's generally a gradual slowdown and is some kind of memory leak type deal. After a half hour or so I need to restart. It seems to be fairly regular.
For Firebug, it's probably been more than a year so it may have been an older version. As a result, I don't remember the specifics, but basically the code was not running correctly and after trying to debug it for a while I disabled Firebug and the code worked fine.
Although alert(msg); works in those "I just want to find out whats going on" scenarios... every developer has encountered that case where you end up in a (very large or endless) loop that you can't break out of.
I'd recommend that during development if you want a very in-your-face debug option, use a debug option that lets you break out. (PS Opera, Safari? and Chrome? all have this available in their native dialogs)
//global flag
_debug = true;
function debug(msg){
if(_debug){
if(!confirm(msg + '\n\nPress Cancel to stop debugging.')){
_debug = false;
}
}
}
With the above you can get your self into a large loop of popup debugging, where pressing Enter/Ok lets you jump through each message, but pressing Escape/Cancel lets you break out nicely.
I use WebKit's developer menu/console (Safari 4). It is almost identical to Firebug.
console.log() is the new black -- far better than alert().
My first step is always to validate the HTML and to check syntax with JSLint. If you have clean markup and valid JavaScript code then it is time for Firebug or another debugger.
Visual Studio 2008 has some very good JavaScript debugging tools. You can drop a breakpoint in your client side JavaScript code and step through it using the exact same tools as you would the server side code. There is no need to attach to a process or do anything tricky to enable it.
I use a few tools: Fiddler, Firebug, and Visual Studio. I hear Internet Explorer 8 has a good built-in debugger.
I used to use Firebug, until Internet Explorer 8 came out. I'm not a huge fan of Internet Explorer, but after spending some time with the built-in developer tools, which includes a really nice debugger, it seems pointless to use anything else. I have to tip my hat to Microsoft they did a fantastic job on this tool.
You might also check out YUI Logger. All you have to do to use it is include a couple of tags in your HTML. It is a helpful addition to Firebug, which is more or less a must.
I found the new version of Internet Explorer 8 (press F12) is very good to debug JavaScript code.
Of course, Firebug is good if you use Firefox.
Besides using Visual Studio's JavaScript debugger, I wrote my own simple panel that I include to a page. It's simply like the Immediate window of Visual Studio. I can change my variables' values, call my functions, and see variables' values. It simply evaluates the code written in the text field.
I'm using Venkman, a JavaScript debugger for XUL applications.
In addition to Firebug and browser-native developer extensions JetBrains WebStorm IDE comes with remote debug support for Firefox and Chrome (Extension required) built in.
Also supports:
coffescript: how to debug coffeescript in node.js with webstorm 6 source maps
node.js
Options to test this for free are the 30 trial or using an Early Access Version.
If you are using Visual Studio, just put debugger; above the code you want to debug. During execution the control will pause at that place, and you can debug step by step from there on.
As with most answers, it really depends: What are you trying to achieve with your debugging? Basic development, fixing performance issues? For basic development, all the previous answers are more than adequate.
For performance testing specifically, I recommend Firebug. Being able to profile which methods are the most expensive in terms of time has been invaluable for a number of projects I have worked on. As client-side libraries become more and more robust, and more responsibility is placed client-side in general, this type of debugging and profiling will only become more useful.
Firebug Console API:
http://getfirebug.com/console.html
By pressing F12 web developers can quickly debug JavaScript code without leaving the browser. It is built into every installation of Windows.
In Internet Explorer 11, F12 tools provides debugging tools such as breakpoints, watch and local variable viewing, and a console
for messages and immediate code execution.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When I find that I have a problematic code snippet, how should I go about debugging it?
Firebug is one of the most popular tools for this purpose.
All modern browsers come with some form of a built-in JavaScript debugging application. The details of these will be covered on the relevant technologies web pages. My personal preference for debugging JavaScript is Firebug in Firefox. I'm not saying Firebug is better than any other; it depends on your personal preference and you should probably test your site in all browsers anyway (my personal first choice is always Firebug).
I'll cover some of the high-level solutions below, using Firebug as an example:
Firefox
Firefox comes with with its own inbuilt JavaScript debugging tool, but I would recommend you install the Firebug add on. This provides several additional features based on the basic version that are handy. I'm going to only talk about Firebug here.
Once Firebug is installed you can access it like below:
Firstly if you right click on any element you can Inspect Element with Firebug:
Clicking this will open up the Firebug pane at the bottom of the browser:
Firebug provides several features but the one we're interested in is the script tab. Clicking the script tab opens this window:
Obviously, to debug you need to click reload:
You can now add breakpoints by clicking the line to the left of the piece of JavaScript code you want to add the breakpoint to:
When your breakpoint is hit, it will look like below:
You can also add watch variables and generally do everything that you would expect in a modern debugging tool.
For more information on the various options offered in Firebug, check out the Firebug FAQ.
Chrome
Chrome also has its own in built JavaScript debugging option, which works in a very similar way, right click, inspect element, etc.. Have a look at Chrome Developer Tools. I generally find the stack traces in Chrome better than Firebug.
Internet Explorer
If you're developing in .NET and using Visual Studio using the web development environment you can debug JavaScript code directly by placing breakpoints, etc. Your JavaScript code looks exactly the same as if you were debugging your C# or VB.NET code.
If you don't have this, Internet Explorer also provides all of the tools shown above. Annoyingly, instead of having the right click inspect element features of Chrome or Firefox, you access the developer tools by pressing F12. This question covers most of the points.
Internet Explorer 8 (Developer Tools - F12). Anything else is second rate in Internet Explorer land
Firefox and Firebug. Hit F12 to display.
Safari (Show Menu Bar, Preferences -> Advanced -> Show Develop menu bar)
Google Chrome JavaScript Console (F12 or (Ctrl + Shift + J)). Mostly the same browser as Safari, but Safari is better IMHO.
Opera (Tools -> Advanced -> Developer Tools)
There is a debugger keyword in JavaScript to debug the JavaScript code. Put debugger; snippet in your JavaScript code. It will automatically start debugging the JavaScript code at that point.
For example:
Suppose this is your test.js file
function func(){
//Some stuff
debugger; //Debugging is automatically started from here
//Some stuff
}
func();
When the browser runs the web page in developer option with enabled debugger, then it automatically starts debugging from the debugger; point.
There should be opened the developer window the browser.
I use old good printf approach (an ancient technique which will work well in any time).
Look to magic %o:
console.log("this is %o, event is %o, host is %s", this, e, location.host);
%o dump clickable and deep-browsable, pretty-printed content of JS object. %s was shown just for a record.
And this:
console.log("%s", new Error().stack);
gives you Java-like stack trace to point of new Error() invocation (including path to file and line number!!).
Both %o and new Error().stack available in Chrome and Firefox.
With such powerful tools you make assumption whats going wrong in your JS, put debug output (don't forget wrap in if statement to reduce amount of data) and verify your assumption. Fix issue or make new assumption or put more debug output to bit problem.
Also for stack traces use:
console.trace();
as say Console
Happy hacking!
Start with Firebug and IE Debugger.
Be careful with debuggers in JavaScript though. Every once in a while they will affect the environment just enough to cause some of the errors you are trying to debug.
Examples:
For Internet Explorer, it's generally a gradual slowdown and is some kind of memory leak type deal. After a half hour or so I need to restart. It seems to be fairly regular.
For Firebug, it's probably been more than a year so it may have been an older version. As a result, I don't remember the specifics, but basically the code was not running correctly and after trying to debug it for a while I disabled Firebug and the code worked fine.
Although alert(msg); works in those "I just want to find out whats going on" scenarios... every developer has encountered that case where you end up in a (very large or endless) loop that you can't break out of.
I'd recommend that during development if you want a very in-your-face debug option, use a debug option that lets you break out. (PS Opera, Safari? and Chrome? all have this available in their native dialogs)
//global flag
_debug = true;
function debug(msg){
if(_debug){
if(!confirm(msg + '\n\nPress Cancel to stop debugging.')){
_debug = false;
}
}
}
With the above you can get your self into a large loop of popup debugging, where pressing Enter/Ok lets you jump through each message, but pressing Escape/Cancel lets you break out nicely.
I use WebKit's developer menu/console (Safari 4). It is almost identical to Firebug.
console.log() is the new black -- far better than alert().
My first step is always to validate the HTML and to check syntax with JSLint. If you have clean markup and valid JavaScript code then it is time for Firebug or another debugger.
Visual Studio 2008 has some very good JavaScript debugging tools. You can drop a breakpoint in your client side JavaScript code and step through it using the exact same tools as you would the server side code. There is no need to attach to a process or do anything tricky to enable it.
I use a few tools: Fiddler, Firebug, and Visual Studio. I hear Internet Explorer 8 has a good built-in debugger.
I used to use Firebug, until Internet Explorer 8 came out. I'm not a huge fan of Internet Explorer, but after spending some time with the built-in developer tools, which includes a really nice debugger, it seems pointless to use anything else. I have to tip my hat to Microsoft they did a fantastic job on this tool.
You might also check out YUI Logger. All you have to do to use it is include a couple of tags in your HTML. It is a helpful addition to Firebug, which is more or less a must.
I found the new version of Internet Explorer 8 (press F12) is very good to debug JavaScript code.
Of course, Firebug is good if you use Firefox.
Besides using Visual Studio's JavaScript debugger, I wrote my own simple panel that I include to a page. It's simply like the Immediate window of Visual Studio. I can change my variables' values, call my functions, and see variables' values. It simply evaluates the code written in the text field.
I'm using Venkman, a JavaScript debugger for XUL applications.
In addition to Firebug and browser-native developer extensions JetBrains WebStorm IDE comes with remote debug support for Firefox and Chrome (Extension required) built in.
Also supports:
coffescript: how to debug coffeescript in node.js with webstorm 6 source maps
node.js
Options to test this for free are the 30 trial or using an Early Access Version.
If you are using Visual Studio, just put debugger; above the code you want to debug. During execution the control will pause at that place, and you can debug step by step from there on.
As with most answers, it really depends: What are you trying to achieve with your debugging? Basic development, fixing performance issues? For basic development, all the previous answers are more than adequate.
For performance testing specifically, I recommend Firebug. Being able to profile which methods are the most expensive in terms of time has been invaluable for a number of projects I have worked on. As client-side libraries become more and more robust, and more responsibility is placed client-side in general, this type of debugging and profiling will only become more useful.
Firebug Console API:
http://getfirebug.com/console.html
By pressing F12 web developers can quickly debug JavaScript code without leaving the browser. It is built into every installation of Windows.
In Internet Explorer 11, F12 tools provides debugging tools such as breakpoints, watch and local variable viewing, and a console
for messages and immediate code execution.
I have a large, javascript heavy web app that I am working on. I am experiencing very slow response times from Chrome Dev Tools for XHR responses and console loggging (3-5 secs). The actual app is running fast and responsive, only dev tools looks like it is suffering.
Does anyone have any idea why Chrome Dev Tools is becoming sluggish as my app grows?
Devtools are like any other debugger; they hook into the normal processing flow of an application, and store quite a bit more information than is normally required. This is much more work than simply rendering the page without debugging enabled, so it will indeed be slower.
That said, 3 seconds to respond to console.log seems high. I'd suggest that you first test the application in a nightly version of WebKit. If it's responsive in WebKit, but not in Chrome, please file a bug against the inspector via http://new.crbug.com/ along with any information you can provide about what scenario causes the slowness.
If it's equally sluggish in WebKit, please file a bug against WebKit's Inspector component: https://bugs.webkit.org/enter_bug.cgi
Either way, post the bug ID here, and I'll see that it's triaged into the correct team.
I "fixed" the slow chrome developer tool by (under SOURCES tab)
clearing the "watch" list that accumulated over time...
clearing all the "snippets", i had dozens as well...
Not sure which of both made the most difference, but it certainly made a difference
This is an old question, but it may help someone landing here later like I did.
Using Chrome 46.x/47.x on Linux (RHEL 7), none of the proposed solutions worked for me. What did work was to disable the setting "Use hardware acceleration when available", in the advanced browser settings.
I noticed in the process monitor/list that the Chrome renderer was taking up a lot of CPU, even putting a breakpoint or stepping throught statements in the debugger would take 10+ seconds!
Might be worth a shot.
Undock the developer tools into separate window.
In my case, it's work.
I struggled with this also, to the point where stepping through code using the chrome debugger was just so slow it took hours away from my productive development time. In watching the CPU utilization when debugging in chrome I would see it use up to as much at 40% of all 4 cores of my processor. I tried everything to no avail. Finally, I tried making the browser window of the page I was debugging as small as I could without losing any of the required view and miraculously it solved the problem. So, now I keep my debugger window popped out in a separate window, and make the window of the page I am debugging as small as I can and my debugging experience is very fast again. I have tested this over a period of weeks and it has held out. Hope this helps someone.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When I find that I have a problematic code snippet, how should I go about debugging it?
Firebug is one of the most popular tools for this purpose.
All modern browsers come with some form of a built-in JavaScript debugging application. The details of these will be covered on the relevant technologies web pages. My personal preference for debugging JavaScript is Firebug in Firefox. I'm not saying Firebug is better than any other; it depends on your personal preference and you should probably test your site in all browsers anyway (my personal first choice is always Firebug).
I'll cover some of the high-level solutions below, using Firebug as an example:
Firefox
Firefox comes with with its own inbuilt JavaScript debugging tool, but I would recommend you install the Firebug add on. This provides several additional features based on the basic version that are handy. I'm going to only talk about Firebug here.
Once Firebug is installed you can access it like below:
Firstly if you right click on any element you can Inspect Element with Firebug:
Clicking this will open up the Firebug pane at the bottom of the browser:
Firebug provides several features but the one we're interested in is the script tab. Clicking the script tab opens this window:
Obviously, to debug you need to click reload:
You can now add breakpoints by clicking the line to the left of the piece of JavaScript code you want to add the breakpoint to:
When your breakpoint is hit, it will look like below:
You can also add watch variables and generally do everything that you would expect in a modern debugging tool.
For more information on the various options offered in Firebug, check out the Firebug FAQ.
Chrome
Chrome also has its own in built JavaScript debugging option, which works in a very similar way, right click, inspect element, etc.. Have a look at Chrome Developer Tools. I generally find the stack traces in Chrome better than Firebug.
Internet Explorer
If you're developing in .NET and using Visual Studio using the web development environment you can debug JavaScript code directly by placing breakpoints, etc. Your JavaScript code looks exactly the same as if you were debugging your C# or VB.NET code.
If you don't have this, Internet Explorer also provides all of the tools shown above. Annoyingly, instead of having the right click inspect element features of Chrome or Firefox, you access the developer tools by pressing F12. This question covers most of the points.
Internet Explorer 8 (Developer Tools - F12). Anything else is second rate in Internet Explorer land
Firefox and Firebug. Hit F12 to display.
Safari (Show Menu Bar, Preferences -> Advanced -> Show Develop menu bar)
Google Chrome JavaScript Console (F12 or (Ctrl + Shift + J)). Mostly the same browser as Safari, but Safari is better IMHO.
Opera (Tools -> Advanced -> Developer Tools)
There is a debugger keyword in JavaScript to debug the JavaScript code. Put debugger; snippet in your JavaScript code. It will automatically start debugging the JavaScript code at that point.
For example:
Suppose this is your test.js file
function func(){
//Some stuff
debugger; //Debugging is automatically started from here
//Some stuff
}
func();
When the browser runs the web page in developer option with enabled debugger, then it automatically starts debugging from the debugger; point.
There should be opened the developer window the browser.
I use old good printf approach (an ancient technique which will work well in any time).
Look to magic %o:
console.log("this is %o, event is %o, host is %s", this, e, location.host);
%o dump clickable and deep-browsable, pretty-printed content of JS object. %s was shown just for a record.
And this:
console.log("%s", new Error().stack);
gives you Java-like stack trace to point of new Error() invocation (including path to file and line number!!).
Both %o and new Error().stack available in Chrome and Firefox.
With such powerful tools you make assumption whats going wrong in your JS, put debug output (don't forget wrap in if statement to reduce amount of data) and verify your assumption. Fix issue or make new assumption or put more debug output to bit problem.
Also for stack traces use:
console.trace();
as say Console
Happy hacking!
Start with Firebug and IE Debugger.
Be careful with debuggers in JavaScript though. Every once in a while they will affect the environment just enough to cause some of the errors you are trying to debug.
Examples:
For Internet Explorer, it's generally a gradual slowdown and is some kind of memory leak type deal. After a half hour or so I need to restart. It seems to be fairly regular.
For Firebug, it's probably been more than a year so it may have been an older version. As a result, I don't remember the specifics, but basically the code was not running correctly and after trying to debug it for a while I disabled Firebug and the code worked fine.
Although alert(msg); works in those "I just want to find out whats going on" scenarios... every developer has encountered that case where you end up in a (very large or endless) loop that you can't break out of.
I'd recommend that during development if you want a very in-your-face debug option, use a debug option that lets you break out. (PS Opera, Safari? and Chrome? all have this available in their native dialogs)
//global flag
_debug = true;
function debug(msg){
if(_debug){
if(!confirm(msg + '\n\nPress Cancel to stop debugging.')){
_debug = false;
}
}
}
With the above you can get your self into a large loop of popup debugging, where pressing Enter/Ok lets you jump through each message, but pressing Escape/Cancel lets you break out nicely.
I use WebKit's developer menu/console (Safari 4). It is almost identical to Firebug.
console.log() is the new black -- far better than alert().
My first step is always to validate the HTML and to check syntax with JSLint. If you have clean markup and valid JavaScript code then it is time for Firebug or another debugger.
Visual Studio 2008 has some very good JavaScript debugging tools. You can drop a breakpoint in your client side JavaScript code and step through it using the exact same tools as you would the server side code. There is no need to attach to a process or do anything tricky to enable it.
I use a few tools: Fiddler, Firebug, and Visual Studio. I hear Internet Explorer 8 has a good built-in debugger.
I used to use Firebug, until Internet Explorer 8 came out. I'm not a huge fan of Internet Explorer, but after spending some time with the built-in developer tools, which includes a really nice debugger, it seems pointless to use anything else. I have to tip my hat to Microsoft they did a fantastic job on this tool.
You might also check out YUI Logger. All you have to do to use it is include a couple of tags in your HTML. It is a helpful addition to Firebug, which is more or less a must.
I found the new version of Internet Explorer 8 (press F12) is very good to debug JavaScript code.
Of course, Firebug is good if you use Firefox.
Besides using Visual Studio's JavaScript debugger, I wrote my own simple panel that I include to a page. It's simply like the Immediate window of Visual Studio. I can change my variables' values, call my functions, and see variables' values. It simply evaluates the code written in the text field.
I'm using Venkman, a JavaScript debugger for XUL applications.
In addition to Firebug and browser-native developer extensions JetBrains WebStorm IDE comes with remote debug support for Firefox and Chrome (Extension required) built in.
Also supports:
coffescript: how to debug coffeescript in node.js with webstorm 6 source maps
node.js
Options to test this for free are the 30 trial or using an Early Access Version.
If you are using Visual Studio, just put debugger; above the code you want to debug. During execution the control will pause at that place, and you can debug step by step from there on.
As with most answers, it really depends: What are you trying to achieve with your debugging? Basic development, fixing performance issues? For basic development, all the previous answers are more than adequate.
For performance testing specifically, I recommend Firebug. Being able to profile which methods are the most expensive in terms of time has been invaluable for a number of projects I have worked on. As client-side libraries become more and more robust, and more responsibility is placed client-side in general, this type of debugging and profiling will only become more useful.
Firebug Console API:
http://getfirebug.com/console.html
By pressing F12 web developers can quickly debug JavaScript code without leaving the browser. It is built into every installation of Windows.
In Internet Explorer 11, F12 tools provides debugging tools such as breakpoints, watch and local variable viewing, and a console
for messages and immediate code execution.
I need to debug JavaScript in Internet Explorer 7.
Unfortunately, its default debugger doesn't provide me with much information. It tells me the page that the error showed up on (not the specific script) and gives me a line number. I don't know if that is related to my problem.
It'd be nice if it could narrow down the error to a line number on a specific script (like Firebug can).
Is there an addon to debug JavaScript in IE7 like Firebug does in Firefox?
Thank you!
See also:
Does IE7 have a “developer mode” or plugin like Firefox/Chrome/Safari?
Web Development Helper is very good.
The IE Dev Toolbar is often helpful, but unfortunately doesn't do script debugging
The hard truth is: the only good debugger for IE is Visual Studio.
If you don't have money for the real deal, download free Visual Web Developer 2008 Express EditionVisual Web Developer 2010 Express Edition. While the former allows you to attach debugger to already running IE, the latter doesn't (at least previous versions I used didn't allow that). If this is still the case, the trick is to create a simple project with one empty web page, "run" it (it starts the browser), now navigate to whatever page you want to debug, and start debugging.
Microsoft gives away full Visual Studio on different events, usually with license restrictions, but they allow tinkering at home. Check their schedule and the list of freebies.
Another hint: try to debug your web application with other browsers first. I had a great success with Opera. Somehow Opera's emulation of IE and its bugs was pretty close, but the debugger is much better.
you might want to try
microsoft script debugger
it's pretty old but it's quite useful in the sense if you stumble on any javascript error, the debugger will popup to show you which line is messing up. it could get irrating sometimes when you do normal surfing, but you can turn if off.
here's a good startup on how to use this tool too.
HOW-TO: Debug JavaScript in Internet Explorer
I've found DebugBar.
Not as good as Firebug, but close.
In IE7, you can bring up firebug lite for the current page by pasting the following in the address bar:
javascript:var firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);
See http://getfirebug.com/lite.html.
Microsoft Script Editor is indeed an option, and of the ones I've tried one of the more stable ones -- the debugger in IE8 is great but for some reason whenever I start the Developer Tools it takes IE8 a while, sometimes up to a minute, to inspect my page's DOM tree. And afterwards it seems to want to do it on every page refresh which is a torture.
You can inspect contents of variables in Microsoft Script editor: if you poke around under Debug > Window you can turn on local variable inspection, watching etc.
The other option, Visual Web Dev, while bulky, works reasonably well. To set it up, do this (stolen from here):
Debugging should be turned on in IE. Go into Tools > Internet Options > Advanced and check that Disable Script Debugging (Internet Explorer) is unchecked and Display a notification about every script error is checked
Create a new empty web project inside of VWD
Right-click on the site in the Solutions Explorer on the top right, go to Browse With and make sure your default browser is set to IE (it's reasonable to assume if you're a web developer IE is not your default browser in which case that won't be the default.. by default)
Hit F5, IE will open up. Browse to the page you want to debug.
VWD will now open up any time you have a script error or if you set a breakpoint in one of the JS files. Debug away!
UPDATE: By the way, if you experience the same slowdowns as me with IE8's otherwise decent debugger, there is a workaround -- if you encounter or make IE encounter an error so that it pops up the "Do you want to debug" dialogue and hit Yes, the debugger will come up pretty much instantly. It seems like if you go "straight" into debugging mode the Dev Tools never inspect the DOM. It's only when you hit F12 that it does.
IE8 has much improved developer tools. Until then it's best to write javascript for firefox first and then debug IE using alert() statements.
Microsoft Script Editor can be used to debug Javascript in IE. It's less buggy than Microsoft Script Debugger but has the same basic functionality, which unfortunately is pretty much limited to stepping through execution. I can't seem to inspect variables or any handy stuff like that. Also, it only shipped with Office XP/2003 for some bizarre reason. More info here if you're game.
I downloaded the Visual Web Developer 2008 Express Edition mentioned by Eugene Lazutkin but haven't had a chance to try it yet. I'd recommend trying that before Script Editor/Debugger.
It's not a full debugger, but my DP_DEBUG extensions provides some (I think) usful functionality and they work in IE, Firefox and Opera (9+).
You can "dump" visual representations of complex JavaScript objects (even system objects), do simplified logging and timing. The component provides simple methods to enable or disable it so that you can leave the debugger in place for production work if you like.
DP_Debug
The IE9 developer tools worked for me. Just set the "Browser Mode" menu item to IE7.
Hey I came across the same problem and found this the application IETESTER. It's pretty awesome, it's an app that has IE 5.5,6, and 7 bundled into it. It doesn't matter what IE version you currently have. This allows you to have multiple versions side by side.
If you enable javascript debugging in IE options and have Visual Studio installed you can even debug the javascript in VS with all the debug options available to you(watches, conditional breakpoints ,etc.)
If you want to start debugging before an error occurs you simply have to put the line
debugger;
into your JS code and this bring you into VS to begin debugging after this statement.
This is absolutely amazing to me for testing backward compatibility for JS code.
Use Internet Explorer 8. Then Try the developer tool.. You can debug based on IE 7 also in compatibility mode
FireBug Lite:
http://getfirebug.com/firebuglite
The answer is simple.
Get Internet Explorer 9
Press F12 to load up Developer Tools
Switch the browser mode to IE7
Running your code through a Javascript static analysis tool like JSLint can catch some common IE7 errors, such as trailing commas in object definitions.
IE8 Developer Tools are able to switch to IE7 mode
If you still need to Debug IE 7, the emulation mode of IE 11 is working pretty well.
Go to menu: Dev Tools, then to emulation and set it.
It also gives error line information.
The following tools works great for me:
1) http://www.debugbar.com/
Provide a convenience UI to with feature like source, style, DOM, Script, HTML check. It also show the actual error in your JS file (which line, which file).
2) http://www.my-debugbar.com/wiki/CompanionJS/Installing
Provide a console for IE6 or IE7 ( which originally does not support)
Screenshot