Debug Faster with F12 Developer Tools in Internet Explorer 9By Louis Lazaris
Can you imagine building and debugging a website’s code without the assistance of some kind of integrated development and debugging tools? For those of us who have been developing sites and web apps for more than a few years, we don’t have to imagine that—it was a reality we dealt with on a regular basis.
But times have changed. The heavy demands and responsibility placed on web developers today have necessitated the rise of developer tools in all modern browsers.
In this article, I’ll walk you through some of the most important features of IE9’s F12 Developer Tools, with a particular focus on what’s new and what’s most practical:
6. Putting it Together
Network Inspection Tab
The Network tab, new to IE9, allows you to monitor and optimize site performance.
To view network resources (as shown above in SitePoint), hit F12 to open the Developer Tools (alternatively you can choose the “F12 developer tools” option from IE9’s Tools menu); then click the Network tab.
For better performance, the Network tab by default does not start capturing resources immediately. To start viewing resources being loaded on the current page, click the Start Capturing button and then refresh the page. Resources will continue to display only in the current tab, and will stop when you’ve clicked the Stop Capturing button or closed the tab.
From a summary view, any item can be double-clicked to bring up a detailed view of that particular item. The detailed view includes request headers, response headers, cookies, and timings.
Data displayed in the detailed view can be exported in CSV or XML format. This option is available by means of the Save icon, which opens up the save dialog shown below:
This can come in handy for sharing information with other developers or filing a bug. There’s even a third-party online tool called the HTTP Archive Rule Runner, which will accept XML-based data and run some YSlow tests against the inputted data for analysis.
DOM elements and styles are also easy to find by opening the F12 Developer Tools and clicking the Select element by click icon.
This option (which is also available in the Find menu, or by pressing Ctrl-B) gives you the ability to select any element and bring up its associated HTML and CSS. Here’s an example showing the SitePoint logo with the equivalent HTML code on display within the tree-node structure:
Once the Select element by click option is chosen, any item on the web page that you hover over will get a blue border (as seen on the SitePoint logo above). This allows you to specifically choose which area of the page you want to examine.
The DOM pane allows you to edit the HTML on the fly and see the changes in the window immediately. To do this, just click the Edit icon and edit the HTML as you would in a regular text editor. When you’re finished editing, depress the Edit button and the changes will be visible in the viewport.
Next to the DOM tree, you’ll see all the CSS styles associated with the selected element, as shown below:
IE9’s F12 Developer Tools let you change the styles on the fly to test and debug the selected CSS.
The styles listed for the selected element are shown in the Properties Pane (the right side of the Developer Tools) in cascading order and according to specificity; hence, the styles that appear at the bottom are the ones that appear later in the cascade, or have more specificity. Overridden styles appear with a line through them, so this can be taken into consideration when trying to debug a CSS problem.
You can alternatively select the Trace Styles option, which will display the applied properties in alphabetical order without selectors present.
Further information about the selected element is available using the Layout and Attributes options. For a more extensive discussion of these features, see Debugging HTML and CSS with the Developer Tools on MSDN.
Back in the Primary Pane (the left side of the tools), you can switch from the HTML tab to the CSS tab. The CSS tab lists all the properties and values found in the selected style sheet, and they’re fully editable, with changes taking effect immediately. The CSS tab also has a style sheet selector that lets you switch between style sheets. This can come in handy on large sites that use multiple CSS files.
Script Debugging and Using the Console
As is expected with any good developer tools, IE9 provides powerful client-side script debugging capabilities that help developers solve issues that might come up when dealing with complex code. To begin debugging scripts on your page, open the F12 Developer Tools and choose the Script tab.
From here, a number of options are available. A drop-down list allows you to select a particular script to work with, as indicated in the screenshot below:
Click the Start debugging button to debug a chosen script. This will unpin the F12 Developer Tools from the browser window, and the script’s contents will appear, along with the Console on the right side, as shown below:
Any script errors present in the page (as in the example above) will automatically display in the Console.
During the debugging process, you can set breakpoints (with optional conditions), control execution of the script, or inspect variables and the call stack.
When the Console option is selected, you can execute statements on the fly by typing them into the console’s command line. The Console feature is new in IE9’s F12 Developer Tools, and provides a number of invaluable features to developers.
Any valid line of code can be run inside a paused script (by hitting enter or clicking the Run script button next to the Console’s command line), as shown below:
If necessary, you can change the Console’s command line to multiline, which will allow you to insert more complex commands and scripts for debugging purposes. Naturally, in multiline mode, hitting Enter on your keyboard will not execute the script; instead, it will move the cursor to a new line. To execute the typed code in this mode, you would click the Run script icon.
Debugging your scripts is just one aspect of the development cycle. In addition to the debugging features already discussed, the F12 Developer Tools allow scripts to be tested for performance using the Profiler tab.
The script profiler feature gives data on the amount of time your scripts spend on custom methods and built-in scripting functions. A button in the Profiler tab lets you start and stop the profiling process, so you can control the data that’s collected.
The screenshot below shows partial results from profile execution on SitePoint’s home page:
The data can be viewed either in Function view or Call tree view, and the resulting data can be sorted and rearranged by clicking column headings or removing headings.
Each time you start and stop the profiler, a different profiling session is recorded. All your profiling sessions are available in a Reports drop-down list and are searchable, as shown in the image below:
The search functionality adds yellow highlighting to your search terms found in the selected report, making it easy to scan for the search results within the context of the report. It also gives you the ability to jump to the next search result using the previous and next buttons. This can come in handy when trying to track down specific method names inside a lengthy report.
Finally, any profile data you capture can be easily exported in CSV format by clicking the Export data icon. This will bring up a save dialog, through which you can store your data locally.
This is just a sampling of the script-enhancing and debugging capabilities available to developers using IE9 and its integrated F12 Developer Tools. With the web app boom in full swing, website performance has never been more important; IE’s tools have made great strides to assist developers in this crucial area of development.
For further information on these and other script-enhancing features, you can check out Discovering Internet Explorer Developer Tools and Profiling Script with the Developer Tools on MSDN.
Changing the UA String and Compatibility Modes
A feature newly added to IE9’s F12 Developer Tools is the ability to change the User Agent (UA) string that’s read by the web server through request headers. Although this won’t make IE9 mimic the rendering of a different browser, it can allow you to run functionality and content that’s targeted to other web browsers (for example, a warning message or other notification for a user with an older browser or browser version).
Different rendering modes for previous versions of Internet Explorer, however, are available using the improved Browser Mode and Document Mode options. Those options are available at any time the F12 Developer Tools are open, as shown below:
Each mode produces a drop-down list of options to change the way the page is rendered. Although these options don’t mimic the original rendering environments exactly, they do provide a fairly accurate and easy-to-use method of testing in different modes:
- Browser Mode—IE7, IE8, IE9, and IE9 in IE7 Compatibility View
- Document Mode—Quirks Mode, IE7 Standards, IE8 Standards, and IE9 Standards
Doing rapid testing for various versions and modes of Internet Explorer has never been easier, with developers standing to directly benefit. For more information on IE Browser and Document Modes, check out these blogs :
These days, sites and web apps are being built with complex scripting. They require more focus on performance and demand faster debugging tools. In this light, IE9’s F12 Developer Tools are much improved. As we near the launch of IE9 in 2011 (the Platform Preview is now in version 7), and as IE9’s market share increases, these and other tools that integrate support for web standards and optimized code will become invaluable to web developers.
Give IE9’s new F12 Developer Tools a test drive to discover whether the new and improved features can help your development for the modern browser. The full “how-to” can be found on MSDN Developer Tools.
Why not take our short quiz for a spin and see how much you picked up from this article.
This tutorial has been made possible by the support of Microsoft. In cooperation with Microsoft and independently written by SitePoint, we strive to work together to develop the content that’s most useful and relevant to you—our readers.