Handling script errors from three different perspectives
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
Comments
Anonymous
April 08, 2009
PingBack from http://microsoft-sharepoint.simplynetdev.com/handling-script-errors-from-three-different-perspectives/Anonymous
April 08, 2009
it seems when you have a lot of sites listed in restrited sites it slows ie8 download http://www.safer-networking.org/en/news/2009-03-25.htmlAnonymous
April 08, 2009
i just noticed today that this blog is finally script error free thats good!Anonymous
April 08, 2009
exactly what i was looking for. thanks.Anonymous
April 08, 2009
Now, it would be even better if we could have the Debug window embeded in the Browser window when debugging :) Second thing, when we perform a search in the 'Script tag' and that a HTML document is loaded, the results that are in a TextNode element (not in a <SCRIPT>, <STYLE> or attribute) should not be shown. If no match is found in the document, a message should say it, rather than closing the search silently. Third thing : when we're debugging, it should be great to have a log of all 'catched' errors via a try block. Sometimes, the error is catched but the program don't work either, and it's very difficult to see where the error is catched. Also, it's not a Script problem, but when we try to select an element with 'Find element by click' and that the currently selected element is not in the loaded DOM of the DevTools, it should automatically update itself (but not more than 15 or 25 updates per time we click 'Find element' because if we're on a zone where innerHTML is setted every 150 ms, we'll turn into an infinite 'reload' loop)Anonymous
April 08, 2009
Faaaaantastic! Debugging stuff in IE6 and IE7 was always hard, but I've finally been able to fix years-old IE bugs with IE8's debugging instead of hacky workarounds :)Anonymous
April 09, 2009
and how to debug a IE8 compatibility issue if there are no error messages of any type (no html errors : xhtml valid, no js errors) ? for example : http://www.preference-formations.fr/index.php?id=107, the ajax autocomplete (try with btsa) works well under IE 7 / FF / opera / chrome / safari and breaks under IE 8 : the links (A tag)seem to be interpreted by IE 8 not as links (no pointer change, no css style hover). With the compatibily mode it's OK : so what's going wrong ? I think it's something relative to js events and callback functions but no js errors are returned by IE8... And with the inspect tool how to inspect a dynamic div (can access to source code with firebug) ?Anonymous
April 09, 2009
@FremyCompany : what do you mean by embedding the debug window in the browser ? If you want, you can pin the window at the bottom of the browser by clicking the button below the minimize/maximize/close buttons of the debug window. BTW : I think it would have been better if this button had a pin icon.Anonymous
April 09, 2009
Using IE8? Issues ? Something broken? Truth is, on Vista I stopped using IE8 in the middle of the betaAnonymous
April 09, 2009
@Olivier : Yes, you can 'pin' the window. But if you start debugging JScript (Script > Start Debbgging), the window is automatically unpinned. The reason have already been explained by the IETeam during a IE Team chat (I don't remind the date, however) : While a break point is encountered, the JScript is interrupted. The problem is that the browser window runs in the same thread as the JScript, so the window freeze. You can't click on the "Continue" button of the developpers tools or do anything because all is freezed. To fix this problem, they have forced 'unpinned' mode while you're debugging JScript.Anonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
By the way, how to see CSS declarations that browser applies by default? In Developer Toolbar for IE 6 and 7 I used to check "Show default style values" in bottom-right corner, and it showed me all CSS properties for current element with current applied values, marked default browser styles with gray. From this I knew, for example, that 'h1' has font-size: 24pt by default, and that body has margin: 10px 15px by default. But I see nothing similar in Developer Tools for IE 8. It only shows styles from author's style sheet, not from browser's settings. It is rather inconvinient.Anonymous
April 09, 2009
There is a quite ugly bug in the german translation: http://www.depon.net/temp/1144139.pngAnonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
oh, nice! the German version is useless! More issues: 1.) Oh, and the one major, important button you forgot on the JavaScript console is the: [ C L E A R ] Clear button! Without it you can't clear any old errors before AJAX/DOM events fire more errors. 2.) There is NO link to the file that threw the error! This was available since the Netscape 4.x days at least!Anonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
I'd like to send feedback on the "Webpage Error" dialog. Why in 2009 on Windows XP and Windows Vista (and Windows 7?) does this dialog and many others STILL have buttons and controls rendered in the ugly styles from 1995 (14 YEARS AGO PEOPLE!) Not only is it horribly ugly but it makes IE look like neglected software that has not been kept up and can't keep up with the pace of modern software design. Task a UI person RIGHT NOW! to get on this and fix every dialog in IE - its a shame that IE has the biggest market share yet is the ugliest browser available.Anonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
@gabe: Yes, putting thousands of sites in the Restricted Zone will slow IE startup performance. It doesn't actually affect "download" performance. @JossB: The script debugger will show the JavaScript as seen by the browser. @steve: I'm not sure what you mean when you say the "german version is useless." @TheUndeadable: Is the problem that the controls are messed up, or something else? Do you ALWAYS see this problem, or do you only see it after you use the dev toolbar to manually force the current document into strict mode? @Buzz: Please provide a URL that reproduces the problem? @PM: Simply click the "Find element by click" icon (the mouse pointer icon in dev tools) to find see the source of the element and determine if there is something overlapping it preventing the link from activating.Anonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
@steve: the quickest way to clear the console is right-clicking in the console and choosing "clear console"Anonymous
April 09, 2009
@EricLaw: Good point. Only after changing the rendering mode.Anonymous
April 09, 2009
@PM: It looks like you're using an outdated version of the scriptaculous library. The current version is 1.8.2 which you can get here: http://script.aculo.us/; it may fix the problem. The specific problem with the site can be fixed by editing /typo3/contrib/scriptaculous/controls.js to comment out the following two lines for IE8: this.iefix = $(this.update.id+'_iefix'); if(this.iefix) setTimeout(this.fixIEOverlapping.bind(this), 50);Anonymous
April 09, 2009
As a full-time web developer (I've been working as a developer for agencies in Seattle since 1996), I'm thrilled to see IE get some of the same features that Firebug offers Firefox. I'm unhappy about the sharing of keyboard shortcuts between the developer tools window and IE 8. If I dock the developer tools, then hit Ctrl-T to open a new tab, I'm told to "Please select an element using the DOM Explorer." Speaking of Ctrl-T -- Why does opening a new tab (Ctrl-T) in IE 8 take 2 seconds on my system? This same operation is instantaneous using Firefox 3. This contributes hugely to a general feeling of "slowness" while using IE 8. I'd like to find out if I can change a setting within IE 8 to eliminate this 2 second delay. The title of the new tab says "Connecting..." during this delay before the title then changes to "New Tab" and focus switches to the new tab.Anonymous
April 09, 2009
@Nick: Slowness in creating new tabs is almost always caused by poorly performing addons. The Java SSV Helper in particular is known to be one issue with addons. The first step is to try in no-addons mode to see if this helps: www.enhanceie.com/ie/troubleshoot.asp#crash If so, then use the Manage Addons tool to look at the load time for each addon and disable unneeded addons. Running with a small set of addons (including a few BHOs) new tabs open on my system in under 200ms.Anonymous
April 09, 2009
EricLaw [MSFT], Well.. Tabs should open fast even if you have many or buggy addons.. Firefox handle this well.Anonymous
April 09, 2009
Shedy, no, Firefox doesn't handle this any better than IE does. If you have slow Firefox addons in Firefox, you have a slow Firefox. http://labnol.blogspot.com/2007/09/firefox-runs-slow-speed-memory-fast.html The difference here is that Firefox users tend to more closely look at what addons they have, and if they install slow ones, they uninstall them.Anonymous
April 09, 2009
@rc: The feature you want was moved into the "Attributes" button under the HTML tab. Click the checkbox at the bottom that says "Show Read-Only Properties" to see all the CSS properties...Anonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
@george: What JS console? The one in Developer tools or the one from Sun?First has such command second had it as well. Second:YOu can disable any and all plugins.Removal for majority is disabled as it is being done in Add/remove(Programs and features) dialog under control panel. But usually disable is enough as it eliminates any call what so ever to it,so its functionality is deactivated. Thos MS plugins you mentioned where older ones and where updated,since usually it was bug in them causing slow init. Why no list?There are tons of variables in play here,various interactions and one some machines one plugin will slow it ,while on the other not. And some of them were in reports/known problems),but not in blog but in connect site. (Which is sadly down)-(Maybe in comments)Anonymous
April 09, 2009
@Travis Leithead [MSFT] No, it doesn't show CSS properties! It shows many read-only DHTML attributes such as offsetHeight, innerHTML and nodeType, but none of CSS - no margin, font-family, text-align etc. This tool allows to add new CSS properties and to assign new values to them, but doesn't show values that already exist. :-(Anonymous
April 10, 2009
@rc: yes, after looking at this again, you are correct. The data is available, but it's not trivial to get it (sorry about that)! Basically, you would need to use the Console to find the element you want to inspect, and then for..in the properties of the element's currentStyle object. I think that's essentially what the IE7 dev toolbar provided.Anonymous
April 10, 2009
@rc: yes, after looking at this again, you are correct. The data is available, but it's not trivial to get it (sorry about that)! Basically, you would need to use the Console to find the element you want to inspect, and then for..in the properties of the element's currentStyle object. I think that's essentially what the IE7 dev toolbar provided.Anonymous
April 14, 2009
Thank you for this! It will make a huge difference in development. Something I did not see, perhaps I missed it, was the ability to view ajax requests, I think most of us are now familiar with firebug and its excellent UI and features. A way of presenting xmlhttprequests similar to that would be a great addition. Other than that IE is fast becomming a great browser for the masses again, so congrats on this. Finally, what about plugins, such things as htmlvalidator, live http headers on ff are extremely useful.Anonymous
April 15, 2009
@James: If you haven't taken a look at Fiddler yet (www.fiddler2.com) I encourage you to try it. It works with IE, Firefox, and all other browsers, and is significantly more powerful than the header-viewing-only plugins. You can not only view, but modify, archive, and compare all HTTP/HTTPS traffic. (FWIW: IE8's developer tools already integrate a HTML validator.)
