JScript Blog : Debugging

JScript Debugger in Internet Explorer 8 Beta 2

deepak.jain — Wed, 17 Sep 2008 12:52:00 GMT

In Internet Explorer 8 Beta 2 JScript team has focused on improving developer productivity. You can read 'What’s new in JScript for IE8 Beta 2' and check out the JScript PM Channel 9 video to learn more. As part of our focus on developer productivity we have continued to invest in the IE8 Developer Tools in IE8 and added a JScript Profiler to the developer tools. You can read 'Introducing the IE8 Developer Tools JScript Profiler' for more details on the profiler. The JScript profiler along with the JScript debugger we introduced in Internet Explorer Beta 1 will help you get your site working correctly and optimally.

In this blog I will give more details about the following key improvements we have made in debugger for beta 2, you can check my JScript Debugger in Internet Explorer 8 Beta 1 blog for more details on the features we released in Beta 1:

Improved script viewer and script explorer
More powerful script console
New execution control features
Better keyboard navigation and overall usability

One of the goals for the script debugger has been to make sure that debugger has minimal impact on your regular browsing. We made that possible by moving JScript engine to debug mode only when you press start debugging. With this, you no longer need to keep debugging enabled in the Internet Options and thus don’t suffer the performance hit. We also wanted to provide you lot of power even when you are not debugging and ensure that you don’t need to transition to debug mode unless you have to debug. Now with Beta 2 we have added some powerful features to make that possible.

Improvements in Script Viewer

The script viewer in Beta 1 showed all the sources when you are debugging but it only showed source for main page when not debugging. Now with Beta 2 you will be able to browse all the sources even when you are not debugging. You can also set breakpoints even before starting debugging. The breakpoints will persist till you close IE window. To make code easier to read, we have updated the source viewer to show sources in syntax color. This is similar to what you might expect in code editors such as Visual Studio.

We have also updated the script explorer dropdown to make it easy to browse and select files. Now the script explorer will show the domain to which the script file belongs to. We have also separated the eval code, other dynamic scripts and scripts executed from Console into ‘Others’ submenu of the script explorer. With this change it will be easy for you to find the script file you are looking for.

Updated Script Console

Console panel in the script tab makes it easy for you to try out new scripts. You can execute the scripts in the console irrespective of whether you are debugging or not. In Beta 2 we have improved the look and feel of the Console so that it is easy to read the output.

To make it easy for you to fix errors on your page, Console also logs all the script errors. These errors will be logged in the Console once Developer Tools has been opened for the tab. You can also navigate to the error location in script by clicking on the error hyperlink in the Console.

To help you log message to Console from your script source we have added support for ‘console’ object. Developer Tools provides multiple level of logging with console.log(), console.info(), console.warn(), console.error() and console.assert(). Instead of using window.alert for debugging, you can use these console commands to log messages to the Console. You can call these console commands with a list of arguments that will be concatenated to generate the output string. The input parameters can also be formatted by using substitution patterns in the style of printf().

You can also control what messages you want to see in the Console pane by using the context menu. Context menu also provide you option to clear the console of all messages. If you only want to clear console.log messages, you can use console.clear().

The console.log is extensible and you can add your own console commands through custom scripts. For example you can add console.debug() command which takes string arguments by using following script –

console.debug = function(){

var args = "";

for(var x=0; x<arguments.length; x++)

{

args += arguments[x];

}

console.log("DEBUG: " + args);

}

This can be easily enhanced to take formatted strings.

More execution control features

The Developer Tools in Beta 1 offered execution control features like Break All, Step In, Step Out, Step Over. In Beta 2 we have added support for Conditional Breakpoints and Break on Error. In conditional breakpoint you can give any valid JScript expression to be evaluated and debugger will only halt if the expression evaluates to true. Break on Error provides a toggle switch to control whether debugger will break on JScript runtime error or continue while ignoring the error. Regardless of the toggle state the error will be logged to the console so that you can investigate them at your convenience.

We have also extended the just-in-time debugging experience of Internet Explorer. Although with IE8 you don’t need to keep debugging enabled from Internet Options, still if you have debugging enabled in the IE and you hit a script error, you now get an option to use Developer Tools debugger. You can still use Visual Studio and other stand alone debuggers by unselecting the check-box in the message and clicking on Yes.

Improved Usability

In Beta 2 we have added extensive keyboard shortcuts. If you have been using Visual Studio for debugging script in IE, you already know the keyboard shortcuts! We have kept the keyboard shortcuts as close to Visual Studio as possible. List of all the keyboard shortcuts supported by JScript Debugger is available here.

We have added search functionality to Developer Tools. Searching in Script tab will show you the search term highlighted in the source viewer. When you browse to a new site or select another file from the source explorer dropdown the search term will continue to be highlighted.

We have also made other improvements like increased tool tips to improve the usability and looks of the debugger.

More Information

For more information on the Developer Tools and JScript Debugger check out these articles:

We look forward to your feedback about the debugger so please leave us a comment in this post. Thanks, and enjoy IE8 Beta 2!

Deepak Jain

Program Manager

JScript Team

IE8 Script Debugger - Under the Hood

Sheetal Kamat — Tue, 18 Mar 2008 12:55:23 GMT

IE8 Beta1 (download available here) now includes a Script debugger that is part of IE8 Developer Tools. This Script debugger was built by the JScript team and I hope you have been using it to fix all script errors when building your web applications.

In this post I will be discuss the design of the script debugger.

The debugger is designed with Active Debugging Framework (more information here). Here is the block diagram of how debugger looks.

A brief description about the different components in the above block diagram:

IE – the host controls the JScript engine by providing the script code and other objects that are needed to execute that code.

The JScript engine is responsible for parsing and executing script code and handling other debugger related operations like stack enumeration, expression evaluation, variable inspection, and both parsing-time and runtime error notifications. The JScript engine interacts with the IE to resolve the external references to named objects (eg. window or document), it also notifies host about execution errors and script state changes.

The Process Debug Manager (PDM) manages various process related information (where is the process running, thread information, parent-child relationship among threads-processes etc.) and also co-ordinates the interaction between all components like engine, debugger, host etc.

Debugger is the component that implements the UI and other functionality that normally comes to our mind with word script debugger.

When we started work on the design for a script debugger for IE8 Developer Tools, the first decision was whether the debugger would be residing in the same process or in a different process. Since the primary reason for building a debugger that is available with IE8 Developer Tools was to provide an integrated debugging experience, we decided to go down the path of building an in-process debugger. Also, having the script debugger in the same process would result in better integration with the host since the debugger will have direct access to host events like say page load and there would be fewer COM calls required to interact with the host or engine.

As soon as we went down this path of having the script debugger in the same process, we hit a fundamental issue, which was that the JScript engine is loaded by the IE UI (rendering engine) thread. What this meant was that when a breakpoint is hit, the UI thread would halt and the script debugger wouldn’t even be displayed. To address this issue, we designed the debugger so that the UI of the debugger would be on a different thread than the script engine.

But with this choice we now had to address the issue of interaction of the debugger with PDM, since this component expects the debugger to be on the same thread. So we split the debugger into two components. The first one, the UI component, renders the debugger application and runs as a separate thread. And the second one, the core or worker component interacts with PDM and host to provide data to the UI component for rendering, and runs on IE’s UI thread.

I hope this blog post explains some of the design decisions of the script debugger of the IE8 Developer Tools and the impact on the functionality of the script debugger.

So how have you been using the script debugger to improve your productivity? We would love to hear from you on your experiences using the script debugger and would also like to know what features you find the most useful.

Sheetal Kamat, SDE, JScript.

JScript Debugger in Internet Explorer 8

deepak.jain — Thu, 13 Mar 2008 12:22:00 GMT

As Shreesh mentioned in his blog, Internet Explorer 8 has a built-in JScript debugger. With Internet Explorer Developer Tools you get a light weight JScript debugger that is well integrated in the browser and available out of the box. This is an in-proc debugger making sure that you don’t have to launch a separate app. It has familiar Visual Studio feel and features like call stacks, watches, locals and immediate window.

To get to the debugger just press SHIFT+F12, or click the developer tools icon in the command bar. After launching the Developer Tools, switch to the script tab.

Before starting debugging you can browse the source code of the websites’ main page and also use immediate window to try out JScript code. You can start the debugger session by clicking on the ‘Start Debugging’ button. The debugger lets you debug even when debugging is disabled in Internet Options Control Panel. This will allow you to enable debugging only for the IE instance you are debugging. All other IE instances will still be in non-debug mode making sure that you don’t get script error dialogs. This will also make sure that debugging won’t have any performance hit on IE instances other than the one being debugged. Debugger will refresh the web page with your consent, in case debugging was previously disabled. If you want to avoid page refresh, you can enable debugging from Internet Options.

After starting debugging, the script debugger provides you execution control. Similar to Visual Studio you can set breakpoints by clicking in the source viewer next to the line number. You can also use context menu or keyboard shortcut (F9) to set breakpoints on the script statement at the cursor location in source viewer. If you have multiple script statements in a line of code, you can set multiple breakpoints on that line and they will be hit based on script statement. In case you want to break execution at first script statement, debugger provides a Break All button in the toolbar.

You can also browse the included files and eval() code using the source explorer drop down list.

While debugging, debugger will also break on script runtime error locations. Debugger will only highlight the script statement that will be executed. On a breakpoint debugger provides you Visual Studio like options to control the execution. You can use following commands to control the execution:

- Step Into: Executes the next statement of script and pauses, even if the next statement is inside a new method. You can either use toolbar button or keyboard shortcut F11.

- Step Over: Executes the next statement of script, continues until the next line of script in the current method, and then pauses. You can either use toolbar button or keyboard shortcut F8.

- Step Out: Continues executing script until the next statement in the method that called the current method. You can either use toolbar button or keyboard shortcut SHIFT+F11.

- Continue: Continue running script without pausing until hitting another breakpoint (if any are set). You can either use toolbar button or keyboard shortcut F5.

At breakpoints you can navigate call stack and inspect local variables. All this functionality is provided in the right hand side tabs of the debugger. Let’s just take a look at each of these tabs –

Locals – This tab displays the name, value, and type of all variables available in the current execution scope. Just like Visual Studio, you can drill down in objects hierarchies and change the value of variables. When you step in or step out the variables which have been modified will be indicated with value in red color.

Watch – Watches are user defined variables or expressions to be watched at each halt of script execution. Like locals you can drill down object hierarchies, change values and observe values changed during stepping through code. Watches can be added either by typing a variable name or expression into the watch window or through context menu available in source view.

Call Stack – Whenever the execution is paused at a breakpoint call stack tab will let you transverse the stack and inspect the variables at that execution context. Double clicking on the stack entry will take you to the location in source code.

Immediate Window – Immediate window can be used to run scripts at the runtime. While on a breakpoint the script will be run in the current execution context. You can also use immediate window for running script while not on breakpoint or even when not debugging. In these scenarios, scripts entered in the immediate window will run in the global scope. Immediate window also gives you option to provide multiline script block by expanding the input window. This can be done using the ‘Multiline’ button. You can go back to the single line input by clicking on the ‘Single Line mode’ button.

Breakpoint – This tab displays all the breakpoints currently set. You can enable/disable breakpoints by using the check box or the context menu. You can also remove breakpoints using the context menu. Double clicking on the breakpoint will take you to the source code. Breakpoints are maintained until IE8 Developers Tools is closed.

This debugger has inbuilt support to debug eval() code and event handlers. You don’t need to enable any options to debug them.

More details on the debugger are available in the Developer Tools Whitepaper. We will also have some debugger videos up very soon. Keep checking this blog. John from IE team has a blog entry describing the Developer tool and also some overview videos. The release notes are available here.

We would love to hear back from you about this debugger. Let us know how this debugger has helped you and also any issue you might have encountered.

Thanks and happy debugging!

Deepak Jain

Program Manager

JScript Team

Jscript debugging: Stepwise instructions and video

rajesh.bhutani@microsoft.com — Tue, 24 Apr 2007 09:05:00 GMT

If you are interested in debugging your Jscript code, then you can use Visual Web Developer (VWD) Express edition, a free download from Microsoft website. Exact instruction on how to use VWD for debugging Jscript are listed at the following blog post:

http://blogs.msdn.com/rajeshbhutani/archive/2007/04/10/debugging-jscript-code-in-ie-using-vwd-express.aspx

If you want to see these steps in action then you can watch the following screencast:

http://channel9.msdn.com/ShowPost.aspx?PostID=301814