JScript Blog : IE

Versioning Language Features in JScript

GauravS — Fri, 17 Apr 2009 01:58:00 GMT

With Internet Explorer 8 we introduced several new JScript language features including native JSON support and accessor methods for Mutable DOM prototypes. Of course, any new language feature introduces compatibility risk and one of the main pieces of feedback we received was that we needed to provide a smart way for developers to opt in or out of these new language features.

So in the JScript engine shipped as a part of Internet Explorer 8, we introduced a versioning switch which enables developers to choose the JScript language set they want to support. Web developers can opt-in/opt-out of select JScript language features by using IE8’s Document Compatibility, which depends upon the layout (or document) mode in which web content is loaded.

Potential Issue: Example

As an example, let’s look at IE8’s native JSON support. We added this support to the engine by adding a global JSON object with built-in parse() and stringify() methods, as per the draft ES3.1 specification, now called the ECMAScript Fifth Edition. Now, for the sake of example, let us pretend that the JScript engine did not allow language versioning and a site implemented a JSON call like this:

1: if(!this.JSON) // check for non-existence of JSON object/functions

2: {

3: //<define a JSON object>

4: //<define a non-standard compliant encoder function – JSON.encode>

5: //<define a non-standard compliant parser function – JSON.parse>

6: }

8: //somewhere in the code

9: JSON.encode(myObj);

For IE7, since no JSON object existed by default, the if check would evaluate to true and the user defined JSON object and encoder/decoder methods would be defined. The call to JSON.encode() would work as wanted.

However, for IE8, the existence of the native JSON object would cause the if check to evaluate to false and no user defined method would be available. The call to JSON.encode() would now fail, which would produce unexpected application behavior, since no such method was defined.

JScript Versioning in Internet Explorer 8 (for Web Developers)

Web developers can now avoid such issues by choosing an appropriate layout (or document) mode for their content. Choosing the layout mode as “Internet Explorer 8 Standards Mode” opts in to the JScript language features supported by version 5.8 JScript engine. Choosing the layout mode to be any mode other than the “Internet Explorer 8 Standards” mode, would imply an opt-in to support JScript language feature set equivalent to the one shipped in version 5.7 of the JScript engine (equivalent to the one shipped in IE7). Going back to the example above, the site owner can either update the code to start taking advantage of native JSON support and use the “Internet Explorer 8 Standards” mode, or can choose any other layout mode to use the existing code as is, thus maintaining compatibility with IE7.

While a dependency on the document mode implies that developers will need to make a switch to both IE and JScript level features and can’t single out/opt-in only to the JScript changes, we did not want to introduce a new version vector specifically for the JScript engine. We wanted to support the same system used by IE8 overall for standards support.

You could read more about IE8’s Compatibility View feature in Scott Dicken’s blog Just The Facts: Recap of Compatibility View and the MSDN documentation for Defining Document Compatibility.

JScript Versioning in other JScript Hosts (for JScript Host Developers)

Apart from Internet Explorer, there are various other hosts such as Windows Script Host, CScript etc. which host the JScript engine, To avoid similar compatibility issues and enable hosts to choose a particular JScript language feature set, the JScript engine now exposes an IActiveScriptProperty::SCRIPTPROP_INVOKEVERSIONING property.

To opt in to a set of language features that should be supported by the JScript script engine, the host needs to invoke the IActiveScriptProperty::SetProperty and set SCRIPTPROP_INVOKEVERSIONING to one of the values below during the engine initialization:

1 (or SCRIPTLANGUAGEVERSION_5_7): To use the language features equivalent to those shipped in Version 5.7 (or IE7) of the JScript engine
2 (or SCRIPTLANGUAGEVERSION_5_8): To use the language features available in Version 5.8 (or IE8) of the JScript script engine. This includes features available in version 5.7 and the language changes introduced in version 5.8.

By default, the set of language features supported by the JScript script engine is set to 0 (or SCRIPTLANGUAGEVERSION_DEFAULT), equivalent to the language feature set shipped in version 5.7 of the JScript engine, unless the host chooses to support a different default behavior.

List of features versioned

Right now, only nine JScript features are versioned like this:

Native JSON support – This would introduce a new built-in JSON object, and the following built-in methods – JSON.parse(), JSON.stringify(), Date.toJSON(), Number.toJSON(), Boolean.toJSON() and String.toJSON()
Support for accessor methods for enabling Document Object Model prototypes
Default the separator to “,” if the separator value is ‘undefined’ in Array.prototype.join
Return the length of the resultant array instead of ‘undefined’ for Array.prototype.unshift
Call toString() if precision is ‘undefined’ instead of throwing a “RangeError” for Number.prototype.toPrecision
Support for array subclassing
Support for trailing commas in object literals
Implemented Error.prototype.toString to provide better error messages
Support for index operator [] on string values

I hope JScript versioning will help ensure that the IE8 end user experience is compatible with IE7 and will give developers some time to update their code to take advantage of these new language enhancements.

Gaurav Seth

Program Manager, JScript

What’s new in JScript for IE8

GauravS — Wed, 25 Mar 2009 05:56:00 GMT

During Beta1 and Beta2 pre-releases of IE8, we’ve blogged about the performance optimizations done in the Script engine and the addition of new language features such as native JSON support. We also provided details about the JScript Debugger and the JScript Profiler –that shipped as part IE8 Developer Tools

One of the big pieces of feedback during our beta cycles was for compatibility, which, for JScript, meant focusing on how we version some of the language features we’re adding. As a result, version 5.8 of the JScript engine (shipped as a part of IE8) introduced an opt-in versioning mechanism for all the new and breaking language features. The JScript engine now exposes new language features only when the layout (document) mode is set to “IE8 Standards Mode.” Versioned JScript language features available in this release include native JSON support and accessor methods for enabling Document Object Model prototypes.

In addition to addressing bugs that were reported during the betas and our internal testing, we have added some user requested changes in the developer tools. A more seamless debugging experience, profiling multi-frame web pages and searching the profile reports using the search bar are some of the cool features we have added. We think developer tools will make life a whole lot easier for you web developers out there – we would love to hear your feedback!

As outlined in the article I wrote in the Code Focus Magazine during beta2, we have made more targeted performance improvements in the JScript engine and the overall AJAX browser stack to improve end-to-end performance of real world applications. On typical AJAX applications such as GMail, commonly used operations have improved over 40% over IE7.

I would like to thank all of you for your support and feedback through the IE8 product development cycle and hope that you like the JScript enhancements done in IE8.

Shreesh Dubey

Product Unit Manager, JScript

Note: The comments on this blog are blocked. Pl post your comments on the IE team blog, so that they can be collated at one place.

Internet Explorer 8 Final Available Now

GauravS — Thu, 19 Mar 2009 19:39:00 GMT

Internet Explorer 8 Final is now available in 25 languages.

IE8 makes what real people do on the web every day faster, easier, and safer. Anyone running Windows Vista, Windows XP, and Windows Server can get 32-bit and 64-bit versions now from http://www.microsoft.com/ie8. (Windows 7 users will receive an updated IE8 as part of the next Windows 7 milestone.)

Internet Explorer 8 Release Candidate Now Available

GauravS — Mon, 26 Jan 2009 23:50:00 GMT

Internet Explorer 8 Release Candidate Is Now Available.

Here is post that would help you Upgrade to Internet Explorer 8 Release Candidate 1.

Note: The comments on this blog are blocked. Pl post your comments on the IE team blog, so that they can be collated at one place.

Gaurav Seth

Program Manager

JScript Team

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

Performance Optimization of Arrays - Part II

JSBlog — Wed, 09 Apr 2008 08:20:11 GMT

Hello Friends,

Hope you have read part I of this topic which I posted few days ago. If not then I would suggest going through that first as this post is just a continuation of that one.

So coming to the point, here is the second reason -

2. “JavaScript arrays are sparse arrays”– JavaScript allows arrays to be sparse therefore, when you write arrayObj = new Array(100); unlike C runtime, JScript doesn’t allocate any slot/memory for those 100 entries up front. It allocates slot for an index only when an index is to be populated with a value, for example…

arrayObj = new Array(100);

arrayObj[10] = 10;

In this example, the array size is 100, but in the actual physical memory there is only one slot allocated for this array. Remaining 99 slots don’t exist at all.

Wondering how this factor contributes to the bad performance? Not allocating memory for all the slots up front is good design. Isn’t it?

Well, JScript always assumed that all arrays are sparse. So even if you had a fully dense array in your code, JScript runtime would treat it like a sparse array only. So if you are going to do a pop() operation on a dense JScript array, JScript just won’t go and delete the last indexed entry and update the length attribute. It does something which is extremely performant for sparse arrays, but equally under-performant for dense arrays. Let‘s see what it is all about.

Internally, for each Array object, JScript runtime maintains a table (different from HashTable, let’s call it TrackerTable) which is nothing but a list of pointers to actual entries in the hash table. So if you just create an Array Object of size 100, and add 10 entries (indexed or named), the TrackerTable will have 10 pointers pointing to actual entries in the hash table. Let’s take one simple example…

arrayObj = new Array(100);

arrayObj[10] = 10;

arrayObj.length = 90;

In this example, I just create an Array of size 100, and populated index 10. Next I reduce length of array to 90. Since the length has been reduced, entries from 90 to 99 have to be deleted. The ideal thing to do would be to delete <key, value> pair from hash table for key = 90 to 99. That means 10 operations on Hash table. JScript is smart here and saves 9 out of 10 operations.

What JScript actually does is that it goes to the TrackerTable, iterates through it, for every entry it checks if it falls between deletion range (90-99 in this case), if yes then delete it. In above example, TrackerTable had only one entry. So instead of 10 operations on hash table, JScript does only one iteration and performs better.

However what if the array was a dense array and all the indexed entries from 0 to 100 were populated? Unfortunately in this case too, JScript would follow the same logic. Therefore it would do 100 iterations over TrackerTable and end up doing 90 more operations.

How it was fixed– As I said in the last post, in IE8 JScript we have the mechanism in place to decide whether an array is a sparse or dense. So we have changed the implementation to take sparse path only when the array is actually sparse. That means for operations on dense arrays, we don’t use TrackerTable anymore. We directly go to the right storage and get the things done in fast manner.

So this is all I had to tell about array improvements. Hope you got an idea of what was/is happening under the hood? If not, do leave a note and I would try to address that. And yes, I have lot many interesting things to share with you all, so keep checking this blog.

-JP

Insight into String Concatenation in JScript

janakiram.msv — Wed, 19 Mar 2008 13:35:00 GMT

Hello Friends,

Have you read my post on the String Concatenation issue? If yes, then I can sense your curiosity to know a little bit more about what went on behind the scenes. For example, what is the new algorithm used to get to the performance results projected in the blog, what were the issues faced, how tough/easy it was to implement etc. etc. Well, I didn’t talk much about all these last time as we were still testing the fix and things were not stable at that point of time. But now since IE8 Beta is out and you are already running it on your box (if not, install from here) and loving it J, why not talk a little bit more and try to get few of the queries answered.

In the new implementation, which is running on your box if you are reading this in IE8, we don’t produce actual regular string for each append operation anymore. Instead, we keep the information about all strings which took part in the append operation. The production of actual regular string is deferred for later point of time.

Let’s apply it on the same example I used in the previous blog post…

resultStr = “Jscript” + “String” + “Append” + “problem”

In the previous implementation, we used to produce the actual string and store it in the resultStr. In the current implementation, resultStr points to a structure (let’s call it pseudo-string), which keeps the details like what all strings are needed to produce actual string and in which order.

The logic looks simple. However there were few issues we faced while implementing it, which I think are worth sharing here…

When to Convert pseudo-string back to actual String – As Eric mentioned in his blog, their ‘Fancy-String’ implementation was heavy as they had to convert ‘Fancy–Strings’ back to regular string every time one is passed by variable reference. We also had this big question facing us – ‘When to convert pseudo-strings back to regular strings’? Should it be done as soon as ‘pseudo-string’ has grown to certain size or should it be done soon after append operation is done? Or should it be done when it is passed by variable reference? We evaluated all these approaches but none of them seemed to be giving the kind of gains we wanted. Later we thought why not defer the conversion to the point when pseudo-string can’t serve the purpose and we have to have the regular string. In other words, do the conversion only when actual regular string is needed. For example do the conversion when a ‘subStr’ or ‘trim’ operation is performed on the ‘pseudo – string’ or when the pseudo string needs to be passed somewhere out of the engine, like IE or VBScript, that doesn’t understand pseudo-strings. We tried it and yes, with this, we hit bulls-eyeJ.

Multiple References to single Pseudo-String

If there are multiple references to a single ‘pseudo-string’, then we want to do the conversion only once. For example…

X = “Hi” + “Microsoft”;

Y = X;

Z= X;

In this example X, Y and Z are pointing to the same pseudo-string. Now if x.toString() is called, one approach is, allocate a buffer of size 11 and copy the strings “HI” and “Microsoft” one by one to the buffer. Later when Y.toString() and Z.toString() are called, we again allocate new buffers for each of them and copy the strings.

Hmmm. with such multiple allocations and copy operations, are we not back to the problem we were trying to solve? Yes, we are.

So how did we address this? Well, we decided not to have X, Y and Z point to actual pseudo-String. Instead they point to a proxy object, which keeps actual reference to pseudo-string. When X.toString() is called, conversion from pseudo-string to regular string happens (a new buffer of enough size is allocated and strings are copied one by one) and the proxy object is made point to regular string. Later when Y.toString() and z.toString() are called, we need not do the conversion again as they point to the proxy-object which already points to the regular string.

So X, Y and Z always point to the proxy-object. Proxy object may either contain a pseudo-string or a regular string, depending upon the time of conversion.

What if Pseudo-string is partially converted to regular string?

X = “Jscript” + “Team”;

Z = X + “Microsoft”;

X.toString();

In above snippet, X is a pseudo string and is used in formation of another pseudo string Z. Now toString() is called on X, so X has to be converted to regular string. Fine. I can do it. But wait a moment. X is used by another pseudo string Z. I can’t convert it just like that?

Well, as I said, all references to a pseudo-string are through the proxy-object. Hence Z also refers to the proxy object for X, not to the actual pseudo-string. So even after X is converted to the regular string, references to proxy object remain alive and things work perfectly.

And yes we had to test it J

‘Maintaining compatibility is priority no. 1’ – this is the mantra we all in the team swear by. At any cost we had to ensure that we don’t break real world when fix is out. Our test team has done an awesome job in ensuring it. They found couple of cool crashes, which were not directly in the new implementation, but because new implementation broke few assumptions made in the engine. Interesting part is that they were reported on the last day of our internal milestones; therefore we had to sit whole night gazing at our screens, fixing and testing them.

This is all about string append problem and I hope it was an interesting read. One more interesting performance improvement I have worked on in this release and would like to share with you all is ‘Arrays’, but we’ll leave that for another post so stay tuned.

- JP

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 in Internet Explorer 8 Beta 1 for Developers

janakiram.msv — Wed, 05 Mar 2008 17:10:00 GMT

Making developers more productive through the design, development, and debug phases of web application development is one of the key goals for Internet Explorer 8. I’d like to take this opportunity to walk you through the features that the JScript team contributed to IE8 Beta 1 for Developers.

Let me start with the JScript language and the scripting engine optimization. Performance of the JScript engine has been our number one goal for the Beta1 release. With today’s rich AJAX web-applications, some of the most common JScript operations include String and Array operations. We received feedback from developers on the slow performance of the inbuilt string concatenation functions of JScript. This is not a new problem and quite a lot has been written about the issue (discussed in this Jscript blog post). With IE8, we fixed this problem in the JScript engine. String concatenation is now many times faster when compared to the previous JScript engine.

Prior to this optimization of string concatenation, most developers used Array join operations to achieve the same result. We were aware of this tradeoff and made sure that the Array operations are also optimized. In either scenario, developers will experience significant performance gains.

One of the challenges for the team was to understand the language compatibility and issues that existed in our JScript implementation of the ECMAScript Language Specification 3rd Edition. We have identified the JScript Deviations from ES3 (discussed in detail in this blog post). This document will act as a starting point for the developers targeting cross browser web applications and helps in understanding the deviations in detail. In the near future, we intend to make JScript more compatible with ES3 specifications.

Another challenge for the JScript developers is the circular memory leak problem. We took a hard look at this problem and realized that this has to be fixed at the COM infrastructure. We implemented a design that bridges the gap between COM ref-counting and automatic garbage collection models. We extended the IDispatchEx interface to enable COM clients to simultaneously live in both the ref-counted and garbage collected worlds. The good news is that since this is impacting the underlying core infrastructure, many built-in COM components including IE8 DOM and custom COM components can take advantage of this.

If you are a web developer, you would have certainly used Firebug or Visual Studio for debugging web applications. Web developers can get started with Visual Web Developer Express for basic debugging or can leverage the power of Visual Studio Team System which is meant for complex testing and debugging scenarios. While we cover the whole spectrum through the Visual Studio family, one of the experiences lacking in Internet Explorer is a built-in JScript debugger. The IE8 Developer Tools now offer an integrated JScript debugger that provides the basic set of debugging features. We believe this compliments Visual Studio debugging experience and is an important step towards making JavaScript developers more productive.

We look forward to hearing about your experiences with JScript and IE8 Beta 1 for Developers.

Shreesh Dubey, Product Unit Manager, JScript

Performance issues with "String Concatenation" in JScript.

shivaram.p — Wed, 17 Oct 2007 15:28:00 GMT

Hello Friends,
I am Jaiprakash and work as a Developer in the Jscript team. There is not much to tell about me except one fact - I can’t recall the last time when any of my teammates called me by my name, they just call me JPJ.

I know, you have seen pretty cool blogs in past from my team mates and I promise this one also not going to disappoint you. So coming to the point, I am going to talk about the famous ‘string append’ problem in Internet Explorer (or Jscript to be more accurate) and how are we going to fix it.

The Problem
let’s do a small experiment to get to it. Copy paste following code in an html file and run in Internet Explorer. Observe the time reported.

On my machine the time reported is 1922 ms (averaged out three times). As you see this code is doing nothing other than appending a 7 character string 20K times. And for such a trivial operation it is consuming almost 2 seconds. Phewww….
Impressed? Not yet. It still doesn’t appeal you? OK. Try increasing the no of appends and enjoy the show. Here is what I get on my box…

Appends	Time (ms)
10K	260
20K	1922
25K	6125
30K	11578

Well, I am sure you would be impressed by now. And I can feel your curiosity to know how Jscript makes such a trivial looking operation such a big one.

Not much, it uses a very trivial algorithm to append strings to get you to such a great show. Whenever it has to append two strings of size ‘m’ and ‘n’ each, it allocates a new buffer of size (m + n), copies the strings one by one, and returns this buffer back. Hmmm. This logic looks fine. What’s the deal then?

Let’s say you want to append 3 strings like following...

resultStr = “Jscript” + “String” + “Append”;

To give you the final result, Jscript first appends “Jscript” and “String”. It allocates a buffer of size 13, copies them one by one to the buffer and assigns the buffer to a temporary, let’s say temp1. Next it appends temp1 and “Append”, allocates a buffer of size 19, copies temp1 and “Append”, and assigns the result to resultStr. As you see, to generate final string for you it copied “Jscript” and “String” twice (temp1 and resultStr) and allocated one intermediate buffer. Imagine what happens when you append ‘n’ such strings. It will allocate n-1 buffers, copy each string (n-i) times where ‘i’ is the index at which the string appeared in the operation.

You might be thinking why Jscript was shipped with such an algorithm. Well, Jscript was meant to be used just as glue, not as full-fledge programming language as used in modern WebApps.

How it affects Real world Scenarios
Gone are the days when web apps used to be static text which was just retrieved from the server and displayed in your browser. Today’s world is AJAX, involves lot more interaction with server, and data received is not just the plain HTML. A modern WebApp fetches data from server; builds the page on your machine using Jscript and DOM APIs, and displays on your browser. And to build the page it has to generate HTML, which is nothing but text. And to generate HTML out of the pieces retrieved from server, it has to append them as strings. And as the applications are becoming smarter and smarter, they tend to minimize the interaction with server, and do as much processing as possible in your browser.

Let me give you some real world examples. You all must have used some or the other AJAX mail client like msn.com, outlook web access or yahoo mail beta. In your inbox, if you scroll down or up, they just update your mail list not the entire page. How it happens? It gets the information about mails from server, builds the table of your mails on the fly and displays in the browser.

Another good example would be Redfin which is actually AJAX based real estate portal. If you search a locality, it shows a map with location of all the results and below the map it shows details of each result. This table it constructs by appending several hundreds of strings.

These are just two. There are many more such. Basically what I want to convey is that string append is a pretty common and basic operation and probability is very high that large number of web apps get affected by this.

So we are fixing it!!!
We are trying an algorithm which avoids those intermediate buffer allocations and repeated copy operations. With this algorithm, I just ran the same test case and here are the numbers for you. Please note that the fix is still under progress so these numbers might change a bit here and there, however they should be enough to give you an idea of improvements.

Appends	Time (ms)
10K	23
20K	47
25K	62
30K	78

Shhhh. Numbers speak for themselvesJ.

JP, I Need this fix on my box, now!!!
I wish I could help you. You will have to wait till next release of Internet Explorer.

At last…
Please help us in helping you. If you have encountered other such script “hairballs”, do leave a note on any of the blogs published here. I want to publish more such blogs for youJ.

- JP

Using Jscript based IE Add-On to export data from any website

rajesh.bhutani@microsoft.com — Mon, 23 Jul 2007 07:31:00 GMT

Often times we browse to a website which has lot of data in tabular format, or we login to secure website which displays data like financial transactions etc. in a neatly formated tabular format. Sometimes we have a need to export such data into another tool, if the website supports such an export good, otherwise we have to manually cut and paste the data into a text file, and painfully convert it into the desired format of the target tool. This process can be very lengthy, painful and error prone. We can use some kind of a script to try to automate some part of this process specially the post processing of the cut-and-pasted data to get into the desired format. But the final process is still not completely automated and has lots of manual steps involved.

What if we can easily write an add-on for the browser which can, not only extract the right set of data from a website we are browsing but can also easily convert it into any format we desire. In this blog post I will give step-by-step instruction on how to develop a Jscript based IE Add-On to achieve exactly such a solution.

In this example we will use an online stocks and mutual funds trading website www.icicidirect.com and write an IE add-on to extract trade transaction details from it, and then to export it in QIF format so that it can be imported into personal finance tools like Microsoft Money.

There are four major requirements for this add-on:

We should be able to invoke it from IE while browsing a web page and it should be allowed to access the contents of that web page.
It should be able to traverse the contents of the web page easily and locate the fields which are of interest.
It should be able to easily convert the data in the desired output format.
And finally it should be able to write the data at the desired location on user machine.

For the first requirement i.e. attaching it to IE, we will make use of the "Adding Entries to the Standard Context Menu" facility in IE. There are many different ways to extend functionality in IE but this one is one of the simpler ones and it satisfies our requirement perfectly. Only thing we need to do for this is to run the following command:

REG ADD "HKCU\Software\Microsoft\Internet Explorer\MenuExt\icicidirect2qif" /ve /d "file://C:\Program Files\EXTENDIE\icicidirect2qif.htm"

What this does is add registry entry for IE to start showing 'icicidirect2qif' as an item in the context menu which shows up anytime you right click in a web page. And when you click on that item IE will run the file "C:\Program Files\EXTENDIE\icicidirect2qif.htm" in context of that web page. The file icicidirect2qif.htm can contain Jscript code written inside the tags <SCRIPT>...</SCRIPT> e.g.

...

</script>

For the second requirement, when IE calls into icicidirect2qif.htm, the script code inside this page can use DOM element "external.menuArguments.document" to access any and all the contents of the web page currently being browsed in IE. In your Jscript code you can use one or more of the properties or methods available in IE to traverse through the 'document' object. Our target web page in icicidirect site had named <text> fields containing the transaction details like 'date', 'amount', 'mutual fund name', 'price' etc. so we have used the DOM call "getElementsByName" to locate and get data for the fields we are interested in, for example "var date = doc.getElementsByName("trans_date"+i)[0];" etc.

For the third requirement, Jscript has a number of useful "String" and "Number" APIs to work with the data we have extracted out of the web page and to convert it to any target format we are interested in, for example we have used code like:

        var units = doc.getElementsByName("Trans_Units"+i)[0].value;
        units = units.replace(/,/g, "");
        amount = new Number(amount); units = new Number(units);
        var price = amount/units;

to automatically calculate 'price' information for a transaction given the 'amount' and 'quantity' information extracted from the web page.

For the fourth and final requirement, Jscript has multiple ways to write data out, one of the simplest method is to use the 'document.write()' API to print output in the currently browsed web page itself. Alternatively you can also access the 'clipboard' object from Jscript and write output into the clipboard which can later be pasted into any application you want. We have used 'ActiveXObject("Scripting.FileSystemObject")' to write out our data into a file on user's machine as follows:

    var fso = new ActiveXObject("Scripting.FileSystemObject");
    var FileObject = fso.OpenTextFile("d:\\export.qif",8,true,0);
    FileObject.WriteLine("D"+date[1]+"/"+date[0]+"/"+date[2]);

In fact there is another ActiveXObject Shell.Application, which can be used in the end to automatically invoke Microsoft Money QIF import tool to start and load the QIF file we have just written out in our example we skipped this because we were writing out an 'investment' account which needs to be loaded into Money using 'File->Import->Restore Account' while the standard QIF import tool in Money works for the normal 'banking' account:

    var oShell = new ActiveXObject("Shell.Application");
    oShell.ShellExecute("d:\\export.qif");
    oShell = null;

Here is the code for the complete "icicidirect2qif.htm":