Tools & Tips

A Peek at Internet Explorer's Developer Tools


I hate debugging, and have never met any developer who argued otherwise. It's a drag to have to go through your code and figure out why it's broken. And most importantly, it's an admission that my code is broken and that I'm not infallible! Heresy, I say!

Seriously though, bugs are simply a natural part of the web development process, and, while we may hate them, we certainly have to deal with them. Front-end developers haven't always had rich debugging tools like other platforms and languages. In the good ‘ole days, alert() was your friend and an important method (excuse the pun) for troubleshooting code. And debugging client-side code has its own unique set of challenges because of the variety of technologies that are in play. If you think about it, debugging pages, especially dynamic ones involves so many moving parts that could affect the rendering. You have the the Document Object Model (DOM), JavaScript, CSS, network traffic, HTTP headers, and many more technologies that all work to produce a page and in many cases interact and affect each other.

Thankfully, times have changed and all the major browsers have built-in tools that greatly increase the troubleshooting features for developers. I give a lot of credit to Joe Hewitt for pushing the tools landscape forward. He created Firebug in 2006. In my opinion, it broke ground on what real browser tools should be.

alt text

Since then, we've seen Firebug evolve tremendously and serve as a baseline for others to work from and we now have powerful tools in Chrome, Internet Explorer, Safari and Opera as well.

For this article, I'm going to focus on Internet Explorer's Developer Tools and the functionality it provides. The functionality I'll discuss will be very familiar to anyone who's used a browser-based debugger but I want to bring focus to Internet Explorer's tools to ensure that there's a good understanding of what's actually available.

Where Are We?

Let me begin by admitting that I know that IE is the browser you love to hate. I get it. The fact of the matter is that it's a major browser that's important to many site visitors and that means you'll be targeting it and also need to debug code in it sooner or later. What's kind of surprising is how many developers don't know that IE ships with developer tools or worse that they think they still need to download the Internet Explorer Developer Toolbar.

The developers tools are commonly called the "F12 Developer Tools" because pressing the "F12" key on your keyboard will open them up while you're in Internet Explorer (interestingly enough, pressing F12 also launches Firebug and the Chrome Developer Tools).

alt text

The developer tools are also accessible via the "Tools" menu under the label "F12 developer tools".

alt text

The key thing I was to stress is that they're included with Internet Explorer (and have been since IE8) so there's no need to install a plugin to get dev tools. Also, while they're called the "F12 Developer Tools", for the purposes of this article, I'm going to drop the "F12" and save me some keystrokes.

The developer tools provide developers and designers with a rich set of tools that can tackle many of the common debugging and inspection use cases they'll face during their work. Capabilities like:

  • JavaScript debugging
  • DOM inspection and manipulation
  • On-the-fly updating of CSS styles and page layouts
  • Networks traffic logging
  • Script profiling

These are features that are par for the course nowadays and essential to determining what ails your pages. On top of this, the developer tools provide the ability to test your site in different versions of Internet Explorer by changing the browser mode:

alt text

Testing for multiple versions of IE has traditionally been a royal pain in the tuckus; this feature aims to lower the friction of ensuring that your sites work across the various versions of IE.

Additional capabilities include such things as:

  • Validating markup against the W3C's validation services for HTML and CSS
  • Prettyfying minified or obfuscated JavaScript code for readability
  • Color picker
  • And more…
  • There's a lot of stuff available so let's review many of the key features.

JavaScript Debugging

I focus a lot on helping developers use standards-based development techniques to ensure their sites work great on IE. As you can imagine, I spend a great deal a time analyzing code, especially JavaScript. So, in order to trace down an odd bug, I need a JS debugger that can let me analyze the code in variety of ways.

Making Code Readable

One of the most important features for me is the ability to prettify JavaScript. I don't know any developer who is not minifying their production code nowadays. And that's absolutely the right thing to do, but, when I need to debug something on a production site - especially where I don't have access to source code - being able to prettify the code is invaluable. Yes, there are online tools like JS Beautify that can do that but it would force me to copy and paste code into it in order to deobfuscate the code. Having this capability built right in saves me a ton of time. For example, say I'm looking at a minified version of jQuery:

alt text

Via the tool icon, I can access the "Format JavaScript” option which will deobfuscate the minified jQuery source code and provide me with substantially more readable code:

alt text

As you can see in the image above, the code is certainly easier to work with. The other cool thing about this feature is that once you've enabled it, it will continue to deobfuscate your JS files during your session.

One caveat is that the deobfuscation process won't revert jQuery to its original source. No service that I know of can do that but source maps will solve that problem going forward. Be sure to read the article on source maps by Sayanee Basu that I just linked to for a great intro on the topic.

Stepping Through your Code

Once the code is readable, it makes it easier to determine the flow of the source. At this point, I can set breakpoints at logical spots in the code to isolate problems as you step through it. And of course, you can set multiple breakpoints across multiple source files.

alt text

You can also specify conditional breakpoints allowing you to break the code flow based on a specific value.

alt text

As expected, you can step into, out of, or over any method you're in providing the granular control you need to check out code and also not waste valuable time. What's important to note is that as you're traversing your code, a call stack is accessible that allows you to see how you got to a specific method or JavaScript file and go back to that method or file to inspect the code:

alt text

In addition, it helps to isolate unexpected code paths that may be the problem point.

Information is key to understanding what's happening and the developer tools works to give you the options to define what you want to see. So along with the call stack, you get information about variables in the current scope via the "Locals" tab:

alt text

Or, you can define your own watch list (via the Watch tab) so you can track how variable values change dynamically based on code execution. The great thing is that the tools give you the flexibility to change the values in either list so you can see how it affects your application.

And let's not forget the Console. No debugger would be useful without a console to output errors and allow you to debug interactively:

alt text

The console will display common errors associated with your page including JavaScript and markup issues. You can also enter commands to interact with the page as well as use the console object within your JavaScript code to display messages to the console.

Evaluating Code Performance

All of the above is great and certainly valuable. An often overlooked aspect of debugging is code performance. Rarely do I talk with developers who mention how they've evaluated their code to determine bottlenecks in slow running methods, especially from third-party frameworks.

The developer tools provides you with a JavaScript profiler that will analyze your code as it's run, providing a wealth of information to use to optimize your code.

alt text

Key bits include:

  • Total # of times a function was called
  • How long the function took to run
  • How long child functions took to complete
  • Type of function (e.g.: DOM or user-defined)
  • The source file where the function is defined

Armed with this information, you can determine whether your method needs to be refactored, if a 3rd party library is causing issues or if a browser-specific method is a bottleneck. To me, the combination of Inclusive and Exclusive Time would be important metrics to evaluate because it would tell me how long a specific method took to run including the time it took child or external methods to complete. From there, I can start drilling down further to nail down the problem code.

Inspecting Network Requests

I'll never forget when I coded my first Ajax request. It was such a small bit of code but it honestly felt magical (yeah I'm weird that way). Doing dynamic DOM updates based on pulling back data from a background HTTP request was incredibly cool and a powerful capability. I'll also never forget the first time I tried to send a result back which ended up generating an error and leaving me dumbfounded. Thankfully, Firebug had a network request inspector that let me check out what my server-side code was returning and troubleshoot it.

The "Network” tab in the developer tools provides this very functionality. It shows traffic related to the page being loaded and exposes details you can use to troubleshoot network-related issues.

alt text

By looking at the traffic captured you can see the type of request being made (e.g.: a GET or POST), if it was successful and how long it took to complete. The network inspector also provides important details about the type of asset you requested (e.g.: CSS or an image) and what type of code initiated the request. This is all provided in a summary view that offers quick details about the requests.

By choosing to go into detailed view, you're able to glean granular information about a specific request. Being able to look at the response body was what allowed me to resolve the problem I mentioned before with my XHR call. But that's only a small bit of the overall data that you get by dropping into detail view. Apart from that you get the request's headers (request & response), cookies that were sent and even timing information that tells you how long the request took.

alt text

The timing display in the summary view is really important because it's a clear visual of which request are long running and might be a problem.

Making Markup Look Good

I'll be the first to say that I HATE testing for multiple versions of Internet Explorer. I'm mainly annoyed with the older versions and I'd be happy if developers could simply worry about IE9 and IE10. But it is what it is and there's a couple of ways of addressing this. You could use multiple virtual machines for each version of IE you're targeting. You could use to virtualize IE versions in the browser. Or, you can use the developer tools' browser mode switching capability to have IE10 emulate IE7 through IE10.

alt text

This tool allows you to change the way that IE renders a page so that it emulates a specific version's capability, thus ensuring that your site should work for that version. Not only does it allow you to specify the browser mode (which determines feature support) but also the document mode (which specifies how a page will be interpreted). This gives you a lot of flexibility to test various versions of IE from a single browser. Just note that the IE team does their best to emulate versions. If you want full-proof testing, then VMs are the way to go. I typically start off with the last option because it's by far the easiest and the rendering is very close to actually using a specific native version of IE.

Inspecting markup is one of the most common tasks for any web professional. It's great to be able to look under the hood at how something is built without having to do a "View->Source”. The "HTML” tab in the developer tools shows all of the elements on a specific page along with their related styles and attributes. This allows you to inspect and update values in real-time and get immediate feedback. You can click on, say, a paragraph element and it becomes editable so you can change the text and see the results immediately. The same applies to the styles and attributes of that element.

alt text

Attributes can also be added inline by right-mouse clicking an element and choosing "Add attribute” from the context menu or by selecting the "Attributes” tab and adding it to the list. The following image shows how I added a color and font attribute to the emphasis element, displaying them as inline styles in the markup and individual attribute lines in the Attributes tab:

alt text

The page's markup is represented in a treeview-style so you're seeing a top-down view of the DOM tree and are able to expand elements to see their children.

CSS also has its own tab, however, it's meant to manage global styles typically stored in stylesheets. Selecting a stylesheet shows all of the selectors, rules and properties defined and allows you to tweak them as you please. In this case, simply unchecking the text-align property dynamically shifted the text to the left:

alt text

It's not only editing existing rules. You can also add new selectors, rules or properties:

alt text

More than a Plugin for IE6

The primary reason why I wanted to write this piece is because I was genuinely surprised by how many developers I've met, who had a misconception about the F12 Developer Tools - or didn't know that they even existed! My hope is that it helps developers get a feel for what's available and makes their troubleshooting a little easier.

I also hope that it generates feedback for future features that developers need. While the existing functionality is good, I'm sure there are a number of new things that you, the readers, would find essential to your debugging experience. Let me know what those are!

Related Posts
  • Code
    Tools & Tips
    Check Out Atom, GitHub's New Development EditorAtom wide retina preview
    It's been awhile since we've seen any updates in the editor space. The last big splash was made by Sublime Text which took the web development community by storm, especially once Package Control came around to serve as the package manager for the editor.Read More…
  • Code
    JavaScript & AJAX
    JavaScript Tools of the Trade: JSBinJsbin retina preview
    We've all been there. There are times when you simply want to throw some JavaScript code up and see how it works. Sure, you could go through the hassle of:Read More…
  • Code
    Tools & Tips
    Browser Testing in the Cloud ReduxBrowser testing cloud redux retina preview
    I've written quite a bit about browser testing solutions trying to help identify techniques and tools that make cross-browser development easier. My last article on the subject covered how to use BrowserStack to test any number of browsers all from one central tool; your own browser. I was on a Windows PC back then so testing multiple browsers was a bit easier and testing tools were mainly complementary to my work. Now that I'm on OS X, the need for tools to round out my testing strategies is even more important, specifically because of the lack of Internet Explorer on the OS. I'm a bit of a stickler for what I install on my computers and I prefer online tools when available. I'm also always on the hunt for new tools that make cross-browser testing easier and decided to give a run. I'll go over some of the key features of the service and how to leverage it to improve your testing capabilities.Read More…
  • Code
    JavaScript & AJAX
    Getting Into Ember.js: Part 5Getting into ember
    Editor's Note: The Ember.js team has shifted to an expedited release schedule and as of this publication date are on version 1.2.0. This tutorial was written pre-v1.0 but many of the concepts are still applicable. We do our best to commission timely content and these situations happen from time-to-time. We'll work to update this in the future. In part 3 of my Ember series, I showed you how you can interact with data using Ember's Ember.Object main base class to create objects that define the methods and properties that act as a wrapper for your data. Here's an example:Read More…
  • Code
    Tools & Tips
    Using BrowserStack for Cross-Browser TestingBrowserstack retina preview
    Browser testing is the bane of our existence. Well, that's a bit of an exaggeration, but not by much. Multiple browser versions and browser fragmentation can make it difficult to get good test coverage for your sites especially when you factor in the different operating systems developers use to build with. Over the years, we've relied on a variety of tools to help us with this challenge including virtual machines, tools that simulate browsers and even having multiple devices on hand to work with. It'd be great if there were a way to have one viewport that allowed us to easily test across any major browser and their individual versions without jumping through hoops. aims to offer this via it's browser-based virtualization service and in this article we'll cover the service and how it helps tackle the cross-browser testing problem.Read More…
  • Code
    The New IE11 F12 ToolsIe11 f12 dev tools retina preview
    Disclaimer: I work for Microsoft Corporation. Back in January, I walked you through the features of Internet Explorer 10's F12 Developer Tools. Microsoft's recent release of Windows 8.1 Preview brings with it, not only an update to Internet Explorer (now at v11) but also a welcome refresh to the F12 Developer Tools. The latter is especially important since developers are dependent on them to troubleshoot site-related issues from within IE. Till now the tools have solved most debugging use-cases but it's clear that as sites become more complex, developers need richer tools to work with. This update aims to bring a fresh look and expanded capabilities for developers with a strong focus on the following: Read More…