For the past several months, I’ve had the unique pleasure of helping to diagnose a variety of web site compatibility problems. Now I realize that I just called debugging web site issues a “unique pleasure”—why? Because I was able to use IE8’s enhanced script error dialog and developer tools! I found that script errors are one of the most common web site compatibility issues—often the source of many visual discrepancies in the layout of a page. These errors raise a lot of questions. What can you do to remedy pages that have script errors? How can you provide helpful feedback to sites that experience script errors? And as web developers, how can you utilize IE8’s built in developer tools to resolve script errors?
In this post, I present three scenarios that you may experience when encountering a page with script errors; for each scenario, I highlight the improvements we’ve made in IE8 and also discuss how you can use these improvements.
“Out for a stroll on the web”
In the first scenario, let’s assume that you know nothing about JavaScript, HTML, or any other technologies that constitute the building blocks of the web. You come across a site that doesn’t seem to be working; perhaps something visible on the website doesn’t look quite right. You might also notice a small “warning” icon in the status bar. How can you fix it?
First, it’s important to remember that users in this scenario make up approximately 99% of people that use a web browser. It’s easy to forget that sometimes. These people want the web to “just work.” User research studies and telemetry data revealed that many users who encounter a web site problem hit the refresh button to try and fix it (possibly because refresh fixes other issues commonly found with slow network connections, such as style sheets or dependent scripts that may have timed out or not fully downloaded; these result in pages that don’t look right). We anticipate that most compatibility issues will appear on sites that are rendered in Internet Explorer 8’s most standards-compliant mode due to changes to comply with standards, and so we use the refresh button as one of the reminders to help users discover the compatibility view button, which may fix the users' immediate issue.
Summary
- Compatibility view: switches IE8’s rendering engine (and DOM) into a legacy mode that is compatible with older browsers (e.g., IE7)
“Customer Service, can I help you?”
In a second scenario, you are on a call or online chat with a customer support representative from a given company’s web portal and have experienced a problem that is preventing you from completing a task. The support representative is trying to collect detailed information related to the problem, whether it is a known issue, etc. What might you need to know?
Most web sites will continue to work (depending on your definition of “work”), despite having a script error. However, in some cases, a script error can completely block your progress. Internet Explorer provides an unobtrusive UI to indicate that the website had a problem. In IE8, as in previous versions of the browser, we provide a notification in the status bar when an un-caught script error occurs (meaning that no error handler or try/catch code on the website stopped the error). To find more information about the script error(s) on a page, simply double-click on that icon.
In IE8, we’ve given the script error dialog a visual refresh (it needed it—compare IE7 vs. IE8 below). We think we’ve really improved the readability of the dialog, and made it simpler to see multiple script errors. We also listened to the number one customer request, which was to add copy/paste support to this dialog. As a result, Ctrl+C will copy all of the errors to the clipboard, whether the dialog is in its expanded state or not, and individual errors can be copied in the same manner after they’ve been selected. The dialog also supports an XML output to the clipboard if SHIFT is held while copying.
Information copied from the script error dialog can be used as feedback to help web sites and support personnel to quickly find and diagnose errors, improving the usability of the site for all visitors.
Summary
- Clearer language in script error dialog (easier to read/understand and less text)
- List view improves discoverability of multiple script errors
- Copy/paste support (users can copy with the Ctrl+C keyboard shortcut or press the “copy error details” button
“Code crunching and bug busting”
My last scenario is likely closer to home for many IE blog readers since you’re probably a web developer. You might author your own pages or know enough to step through someone else’s code and understand it. You’ve just started building a new website and have run into a script error. IE8 can help.
To demonstrate one of the major improvements we’ve made in Internet Explorer 8, consider this example where a webpage is using script hosted as an external resource (a very common design pattern). The primary document (index.html) contains the following:
1: <!DOCTYPE html>
2: <html>
3: <head>
4: <title>Getting started</title>
5: </head>
6: <body onload="begin()">
7: <script type="text/javascript" src="external.js"></script>
8: </body>
9: </html>
The source for the external script “external.js” is the following:
1: /* external.js */
2: function begin()
3: { 4: var oDiv = documnt.createElement('DIV'); 5: }
With IE8, we’ve fixed a few long-standing bugs, and are now able to report the correct line number and file where the error occurred:
Web developers often need a little more context about a problem involving a script error, and using the script error dialog is only the first step. The real bread-and-butter for the web developer is the built-in developer tools; in IE8 simply press F12 to open them. While debugging script errors, you’ll spend most of your time in the Script tab of the tools:
We’ve made it much easier to work with the IE8 built-in script debugger or any other script debugger that you have installed. By default, script debugging is disabled so that browsing performance is not adversely affected. To get started you have to enable debugging. To do this in IE8, you don’t have to search through the Internet Options control panel to turn on debugging (and then possibly forgetting to turn it off again later). Instead, just push the “Start Debugging” button and debugging is enabled for that process (and will persist until the process is closed). Note that the Start/Stop debugging button in the Developer Tools does not affect the IE-wide script debugging setting in the Control Panel options. Because break-on-error (the pause button with the red X) is enabled by default, the debugger immediately catches the problem, and indicates exactly where the error has happened in the source view of the tools (see previous screenshot).
With debugging enabled all script errors automatically propagate to the console window. You can quickly find where each error occurred in the context of the source code simply by clicking on the location information to the right of the error message. Additionally, you can see where you are in the execution context call stack (the “begin” function, after the global “onload” handler), inspect local variables, watch any expression, step through the code, and basically do the activities you’ve come to expect from a debugger. The Developer Tools also offer a way to quickly switch between all the script and source files loaded for the current page. More info can be found at the Jscript debugging documentation.
Here are three tricks that I find pretty handy while working in the Script tab.
Break All - The “break all” button (the pause button to the immediate left of the break-on-error button) causes script execution to pause the next time any script would be executed. On simple pages this can be very handy. For example, assume that the begin function was actually triggered by ‘onclick’ instead of ‘onload’. With the debuger running, pressing the “break all” button will allow you specifically trigger execution paths that you want to debug—in this case, when you clicked on the body element, you could then trace the JavaScript execution from that point on. This doesn’t always work well because of script that runs as a result of a timer. For those scenarios I’ll use the search box to find the function and then set an explicit breakpoint.
Right click and add watch - when I want to watch a specific variable, it’s as easy as finding the variable in the source window, right-clicking on it, and selecting “Add Watch”. This technique will grab only the variable and place it in the Watch window along with its value and type. To add an entire expression, simply highlight it and right-click on the highlighted expression and select “Add Watch”.
Console window – often when the debugger is paused, I take the opportunity to execute a few investigative variable queries using the console window. To really take advantage of the console window, consider using console logging. Console logging provides an asynchronous alternative to alert() for those that prefer that debugging methodology. console.log() provides the same functionality as alert(), but does so without creating a modal window (and the focus switching that goes along with it). The console object also supports the different logging levels: log, info, warn, and error as shown below.
External script debuggers
If you want to launch an external script debugger like Visual Studio 2008 from within IE8, you’ll still need to turn on script debugging for IE in the control panel. After that, if Internet Explorer comes across a script error, it will give you the option of using IE8’s built-in developer tools or some other debugger:
However, when Visual Studio 2008 launches IE8 for debugging purposes, it automatically enables per process debugging so that you don’t have to manually switch it on/off.
Overall, IE8 provides a premier set of developer tools, of which I’ve only discussed some of the features available in the Script tab. Profiling, HTML and CSS inspection and editing, and layout troubleshooting are among some of the other features built-in to the tools that are available now with IE8. With the developer tools, web developers have the tools they need to troubleshoot script errors and quickly fix them.
Summary
- Accurate line/file information in script error reports
- Debugging can be automatically enabled on a per-tab bases through the developer tools
- Full-featured script debugger built-in to IE8’s developer tools
With IE8, handling script errors is much easier whether you are an end-user or a web developer. I hope you have as much fun using the tools as I’ve had.
-Travis Leithead
Program Manager