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 re-
installing 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.