Javascript Debugger

Javascript Debugging in Internet Explorer using the MS Script Editor - A fully functional and robust debugging environment for Javascript programmers developing for Internet Explorer I’ve finally found a good Jscript/Javascript debugging solution; it sounds vanilla and mundane, but after researching for days, I found a guy on a USENET group who mentioned his group is using the Microsoft Script Editor included as a stand-alone utility with Microsoft Office with FrontPage 2003 and FP_XP. This is a commercial use release of Office for corporate customers. This editor may also be included with other versions of Office as well. It may also be included with any recent version of Frontpage. The MS Script Editor is an amazing IDE for script development and has a javascript debugger built into it that is closely tied to IE6 and allows for seamless Javascript debugging of very sophisticated web-based applications. Not to be confused with the lackluster Microsoft Javascript Debugger (1997), the Microsoft Script Editor (2001) is a fully functioning editor/debugger that is very robust and has never crashed for me after many months of use. Best of all, it’s FREE if you already have one of the many MS products that includes it as an optional feature. Since Microsoft obviously does not wish to support JSP developers with their current flagship developer products, this is an amazing godsend for Java/JSP programmers developing for Internet Explorer. My company invested $1200 into an MSDN license, only to find that the free OfficeXP Scripting Editor worked much better than Visual Studio.NET, which does not support JSP development. And look across the internet; you won’t find a better solution than the one listed below if you are a Javascript/Jscript developer oriented to IE. NOTE: it is not necessary to have Frontpage installed on your machine to use the Script Editor. The script editor is an add-on in the tools area of the OfficeXP INSTALLER (probably 2002 as well) CD. I have “Microsoft Office XP Professional with Frontpage” installed on my PC. I uninstalled the old Microsoft Javascript Debugger (1997), (crashes and is horribly obsolete) before following the procedure mapped out below.

Chapter 1.

INSTALLING THE MICROSOFT SCRIPT EDITOR

1) From the Start Menu, if Frontpage is listed, start it, and search on the help files for "Script Debug".

If Frontpage is not in your start menu, it is possible to add only the script editor as a standalone application: - Go to Control Panel, Add/Remove Software and open the Office Add/Remove/Repair function. Here you can look for Office Tools, Script Editor and Debugger and set it to run from your hard disk. This should install the editor from CAB files on your hard disk, but it may be necessary to use the Office CD as an alternative.

2) Start the Scripting Editor found under Tools/Macros/Script Editor in Frontpage. If you loaded only the script editor, the target is: C:\Program Files\Microsoft Office\Office10\MSE7.EXE and you can put a shortcut for it in your quickstart menu with this path. 3) Once the script editor was started, run the Web Debugging option under the Debug Menu.

This will prompt you to install the debugging features and warns that the editor will have to be restarted to use the Debugger. Order of install is important; don't uninstall the MS Script Debugger after installing the MS Script Editor; it will mess up your registry settings and you will have to start over from scratch by first uninstalling the Script Editor and then reinstalling it. Chapter 2.

USING THE MS SCRIPT EDITOR

1) Add the “debugger” keyword to any script, and it opens the script editor at that point, when the script is run in the browser. The debugger should come up when the browser issues an error alert. At first this was not working for me, but I went into the IE options panel, under Advanced and turned off “Hide scripting Errors” option, as well as turned off “Friendly Error messages”. I also had to turn on the Status Bar under the View menu. The debugger will also come up if you have a script debugger entry in IE under the View menu, like this: debugger;

Click Yes.

Click Yes. 2) You may be prompted to run a regedit script the first time you try to use the debugger. Open a CMD window and run the path in the prompt, to set the proper Registry settings (notice it’s forward slash before the RegServer argument): “C:\Program Files\Common Files\Microsoft Shared\VS7Debug\vs7jit.exe” /RegServer NOTE: if by now, installation has not progressed as described above, try running the script above, and then logout and log back in again to be sure your machine as reloaded the registry and is now seeing your modifications.

3) Notice once the editor opens, the script is now open in the editor, and you have yellow highlighted line and pointer where the debugger keyword was used in the script. Look at the top of the window, and it lists the file currently open and the path to the file. This has saved me many times when I was editing the wrong file and could not see my changes showing up; I simply activated the debugger and found the correct page I needed to be editing! 4)

There is a third way to force the debugger to open when interactively working with a page in the browser. Use the View menu, and you should see a new Script Debugger entry which has an option for “Break at Next Statement”. Once you select this, the next click on the page will force the debugger to open at whatever point in the code is issuing and handling the current event. Keep in mind, many times this will put you into an HTML page, and you will have to click on the debugger’s “Step Into” function to force the debugger to open the associated .js file if you are using JS include files.

The View menu allows entry straight into the debugger on the next click event. 5) Under the Debugger menu, there are now all the typical debugging commands available.

Also notice: a) Expression evaluation is available is Quick Watch, and vars can be added to a Watch List. b) DOM objects may be inspected in the browser document tree, as to ID, ParentId, etc and the entire DOM tree can be walked thru in it's full heirarchy. c) Stepping thru the script is easy with Step In, Step Over; break points may be added in the usual fashion (left margin toggle click). d) .JS files will be opened as the program execution requires (the application I am working on opens several .js files in a row) e) A toolbar for the debugging commands exists but will need to be configured and placed in the menu bar (similar to IE). f) All debugger commands have keyboard shortcuts that speed things along...

When the debugger first comes up, it will point out any error the browser found.

Use the Quickwatch page to inspect a page object or javascript object, revealing it’s properties in an expanded view. Walk the DOM up or down and see all currently set attributes and innerHTML content!

Use the Quickwatch command to evaluate a current object or variable selection, then add it to the Watch list at the bottom of the editor window. Notice breakpoints have been set by clicking on the left margin of the page. 6) Also refer to the Help file in the Script Editor for debugger commands help. It's short and sweet.

A few quick notes regarding the use of the debugger and Javascript error handling: -

Use the debugger keyword in your script to bring up the debugger at a point before you need to find a scripting error. Often it is most effective to simply put “debugger;” in the same line in your HTML that calls the function you want to debug: onClick=javascript:debugger;functionCall().

-

Once you have arrived at the line throwing the error, you may inspect all variables current values by using the Evaluator window (magnifying glass on the toolbar).

-

You will not be allowed to proceed in IE until the debugger is past the current break point or step. If it is stuck on an error, use the “Play” or “Stop” icon in the toolbar.

-

If you are using a variable to collect HTML and then write it to the page with document.write, the HTML source will not be viewable with the view/source option in IE. It also will not be visible to the debugger, and the debugger will report it cannot preceed into the code currently being executed. If you must see the rendered HTML/JS it is possible to do a window.document.write(var) that points to a popup window previously opened for the purpose of writing into it (where “window” is a var that equals the popup window, like this: var newWin = window.open(‘’,’newwin’, 500, 500); Then use view/source in the popup to see the source of the newWin.document.write(var). You may then run the debugger in the new window.

-

Sometimes it may be difficult to know if an error is caused by a problem before or after the page has been submitted. For Java developers, often problems are reported by JSP or Java class files after the request object is submitted to the application server, but the error is in the javascript before submission. This is easy to check by viewing the submitted request object in a Java IDE. Attach or connect your debugger and submit the page or run the function that submits to the application server. It is possible to not only view the Javascript as it runs pre-submit, but then open the Java IDE debugger (Eclipse will probably work, or use IDEA) and interrogate the request.parameters.HashArrayParameterString and view the value attached to the parameters in the submit to be sure they are all populated as you expect them to be submitted to the application server. If they are not, your problem in the JSP or Javascript prior to page submit. This helps narrow down unexpected problems quickly, (except when your JSP suddenly starts failing to compile ;-) - With a java IDE and the MS script editor, it is possible to watch the entire execution path of your web application run from button click to the rendered response in your browser window. However, keep in mind the browser runs in a threaded fashion, and sometimes when you expect a JS statement to work, it will not, for non-obvious reasons. Keep in mind the browser has memory allocation issues particular to referencing existing variables and objects. If your script is not working and the debugger is not helping you, I find it helps to study Javascript memory allocation issues regarding references to existing vars and arrays, vs constructing fully memory allocated datastructures. It will occasionally be necessary to know more about Javascript than the debugger is capable of demonstrating to you. Sometimes, putting a statement inside of a setTimeout call can force a new execution thread to start and solve problems if the javascript interpreter is becoming confused and fails to execute as you expect. Or use an eval() function. Or possibly use document.body.onclick = functionCall() to kick the javascript into action. Problems in Javascript are sometimes evident when code properly executes after a debugging alert comes up, but does not run if execution is not first interrupted by the alert. This points to interpreter execution bugs or loss of the thread because it’s left open and hanging somehow, and may require the setTimeout to force a new thread to take up where

the old one failed to execute the line in question, at least as a temporary workaround.