What’s new in F12 with Windows 8.1 Update

We are excited to announce a set of substantial updates to the developer tools in IE, (F12) as well as in Visual Studio 2013 Update 2. The updates in F12 accompany the new releases in IE11.

Previously, we described the capabilities of F12, and its focus on a fast, iterative workflow, on providing accurate data in the DOM Explorer and on providing actionable data in the memory and performance tools.

As you use F12 with this update, you will notice enhancements for the following:

A tighter, iterative workflow with change tracking in the CSS tools

An ability to debug in the code you wrote such as CoffeeScript or TypeScript, with sourcemaps support, and debug “just-my-code,” if you are using libraries from other developers

Enhancements that get you to solutions faster, for example when finding memory leaks, with the enhanced JS snapshot tools and filtering improvements.

Let’s take a look at these improvements to the F12 tools.

Tracking Changes you make in CSS with Change-bars

One of the great strengths of tools like F12 is they allow you to edit the look of any Web site directly within the browser, without you requiring our source code. However, if you spend time making edits it is difficult to keep track of all the changes you make across your CSS and then applying those final edits back to you origin sources. To improve this situation we have introduced an ability to record and track changes, both visually with ‘change-bars’, as well as through a new ‘Changes’ CSS panel in the in the DOM Explorer.

Any change you make in the Styles pane in the DOM Explorer to CSS rules and properties will have a visual clue in the left-margin next to the property or rule that you edited. These are the ‘change-bars’, and they show green for new properties, yellow for changed properties and values and red for deleted properties. These change-bars will be retained, even if you begin to look at other DOM nodes.

Changebars on the Styles tab

As you may make multiple edits across many nodes, we added a new tab in the CSS panel that lists all the changes in the current F12 session, as a ‘diff’ view so that you can use it as a checklist when you make manual edits to your source code. It also supports the ability to copy and revert changes through a context menu.

The new Changes tab

Debugging your App with “Just My Code”

If you are developing Web sites and apps, then you are likely using 3rd party libraries like jQuery or Angular, and typically these libraries are often minified. We often see developers who are debugging their code step into library code, and get buried in the depths of that library, before being able to get back to their code to debug their issue.

Visual Studio has supported a feature called “Just My Code” (JMC) managed languages for a while and with Visual Studio 2012, it is also enabled for JavaScript. The idea behind JMC is that we keep the debugger in your code, in the code you want to debug and not into code you can’t really change.

With this feature now in F12, there are two key things you will see when you debug

You will never ‘step into’ a file (library) that is marked as library code. You can mark a library through the file picker in the debugger (see below), even if you have stepped into the file. Once marked, any step operation will take you to your code.

If you enable “break on all exceptions” you will never break on an exception thrown and handled in library code.

Marking files as library code

By default F12 will recognize files that match the URL *.min.js as library code. You can modify this behavior easily however, by marking libraries in the debugger’s file picker or in the context menu of the file tab if you have the file open in the debugger.

We will show much more about this feature and the workflow in a follow-on blog post.

Debugging your App written with other Languages using Source Maps (v3)

As JavaScript apps have become more and more complex recently there’s an increasing trend to author in another language that compiles to JavaScript (the F12 tools are written in TypeScript and compiled to JavaScript for example). Similarly, you may have minified JavaScript code that is not the origin source that you wrote the app in. This compilation process means the JavaScript that executes in the browser and that you debug, isn’t the code you have in your editor, which makes debugging more challenging.

To solve this problem, there’s a community-driven format that has gained a lot of traction with browsers and Visual Studio, that maps origin source and compiled files called “Source Maps” (spec). These maps are generated during compilation and with this release of F12 we’ve added support for v3 of the Source Map spec.

When a compiled JavaScript file defines a valid source map, F12 will default to load the original source file, rather than the running JS file, when ‘source maps’ are turned on (a button on the debugger). You will have the following capabilities:

Files in the file picker use their origin source name, rather than the running documents.

The file(s) you open in the debugger, and use to step through your code are your origin source files, and for TypeScript, CoffeeScript and Script # these files will be colorized appropriately (as you can see with the TypeScript file below).

As with Just-My-Code, we will go into more depth on source maps in a follow-on blog post.

Three way snapshots

When debugging a memory leak, you typically will be presented with a large amount of data, even if filtered) that memory profilers create, which makes finding that leak complicated. In F12 we had previously taken steps for the tools to summarize the state of the app in the snapshot tiles, and opportunistically suggest potential issues with the detached DOM information indicators. However, in this update, we wanted to take this further, by helping developers zero-down on issues even easier.

The F12 Memory tool now includes the ability to compare three snapshots (and get a scoping view of those snapshots), that is a cleaner process to determine a leak. The snapshots are:

The initial state of your app before you start the scenario that provides the baseline for objects in your app.

Once your scenario is completed, which may augment the possible baseline for your app, which then requires a further snapshot once you execute the scenario again.

The ‘back to normal’ state of your application, once you try the scenario again. In this state all of the objects from your scenario should have been freed (or you expect them to be alive).

With these snapshots you can compare them and use the new “Scope” filter dropdown to select the “objects left over from snapshot #2,” which represents your scenario end state and potentially a set of objects that shouldn’t be around anymore, as shown below.

Scope filter

The types view that you see above, shows the list of objects and a gutter indicator of where potential issues may reside.

Tooling for IE on Windows Phone in Visual Studio 2013 Update 2

If you have spent time trying to make a compelling mobile version of your Web site you have likely hit issues with it not looking or working correctly on mobile browsers. To help with this on Windows Phone, we’re excited to announce that in Visual Studio 2013 Update 2 we have enabled the use of Visual Studio’s debugging and performance tools for Internet Explorer on Windows Phone 8.1. For more details on this have a read of the Visual Studio ALM Blog on this topic.

Many other improvements…

In this release of F12 we’ve tried to address many customer requests, as well as address bugs that include several crashes caused by the network inspector and not respecting conditional comments when using F12 to emulator lower document modes. Rather than the list the bugs here the bugs will be updated on the Microsoft Connect site for IE (https://connect.microsoft.com/IE/Feedback).

Here’s a more detailed list of the changes you’ll see in this release of F12.

Shell

Ctrl+[ and ctrl+] to navigate between tools

Console

Dropdown to enumerate execution targets.

Inspect objects that are logged via console.log including printf-style formatting.

Locals (at breakpoint) in intellisense for the console.

Console $_ shortcut to access the result of the last evaluation in the console.

Updates to the types views to show which type(s) accounted for the majority growth in a diff, so that you can rationalize object churn more easily.

Gridlines on table UI.

Settings UI (show built ins, circular refs, object ids).

Summary

With this update to IE11 and F12, we’re updating developer tools more often getting you the latest features and bug fixes as soon as we can. Expect to see and hear from us more and if you’d like to provide feedback, or ask for new features and help simply reach out on twitter @IEDevChat, or through the IE11 Send Feedback tool or on Connect.

This post just scratches the surface of what’s new in F12. Over the next few weeks we’ll be publishing blog entries that go into more depth and show you how to use F12. There’s also our complete F12 developer tools documentation on MSDN.

In the meantime, we look forward to your feedback. You can reach out to the team on Twitter @IEDevChat, through the IE11 Send Feedback tool or on Connect.

@The Deeds – Thanks for all the feedback, for each item you mentioned:

Color picker – This is on our backlog but isn't near the top

Ruler – This is on our backlog but isn't near the top

font-face – Working with font-face and keyframes and the like is a feature that's high on our backlog

F5 – The F5 key when focused in F12 is meant to 'continue' which only works when broken in the debugger, we don't intend on overloading this key usage with refresh for the page. If your focus is on F12 you can press F12 to focus on IE and then F5 to refresh. If you're pinned this will hide F12 if you're unpinned it will just change focus.

multiple select in styles – This is on our backlog near the top

Edit tag name – I've added an item to our backlog for this, you can do it via edit as HTML today but as you call out there isn't an easier mechanism.

@Arieta – Thanks for the feedback, I've added a note to a feature on our backlog for previewing/opening URLs wherever we show them.

@ididit – VS will attach the script debugger as well as launching the DOM Explorer and the console in Visual Studio (we ship the same tools in F12). The F12 key then brings VS to focus when you hit. In general the F12 key is used to bring up the tools and if you attach with VS the tool is VS as both F12 and VS can't be debugging the same page at the same time. Also if you hit F12 while on F12 we should bring IE into focus.

@ZippyV – Adding a CSS view to the tools is on our backlog, and near the top, I've +1 the feature.

So am I correct in understanding that IE Conditional Tags will now register correctly in IE11? I feel like if this is so, it should be made very clear that this now works, as this was the main reason I REVERTED back to IE10.

@slawek – Thanks for the feedback, resource views for cookies, local & session storage, and indexedDb are all on the backlog. Though cookies and storage are higher up than indexedDb.

@MgSm88 – The update is distributed via Windows Update and should be available for download.

@Bryan – Yes conditional comments should work when using F12 to change document modes. Conditional comments were always supported in document modes < IE10 (they were removed in IE10 msdn.microsoft.com/…/hh801214(v=vs.85).aspx) just not when set via F12 :(.

I still don't like the tabs being vertical, my most commonly used are at opposite ends and it really slows down debugging. Can't we have them horizontal again like debuggers in all other browsers? Or at least an option to switch.

F12 is great however if IE completely freezes how would you debug the issue. I am having a problem in my current website where i am using multiple javascript plugins and something in those plugins makes IE9 completely freeze. Same code works fine in higher versions of IE.

@AndySterland, thanks for your patience. I have two requests about the shortcuts. The following works in all major non-IE browsers:

/start-quote

Missing shortcut in IE:

While holding the Ctrl button, if you press browser's back or forward button it should open the corresponding (previous or next) page in new tab. This behavior is present in Firefox, Chrome and Safari.

Incomplete implementation in IE:

While holding the Ctrl button if you press 0 (zero) on qwerty keyboard, the zoomed page is reverted to normal. But if the 0 is pressed on num-pad, the shortcut doesn't work.

In this case; what are the steps of reproducing this issue? Have you filed a bug report on Connect (link please)? If you don't have time or don't want to report it properly, please don't brag about it improperly.

Since things have changed @Microsoft and I (Cortana) am looking after your issues too. Thereby, I would highly suggest you to regain trust on IE's Connect channel and make a bug report for each issue you face in IE. IE team will respond to those!

"always record developer console messages" appears to be buggy. With it turned on I am seeing what look like "replays" of console messages for old version of a js file, not the behaviour I'd expect after the changes I've made. I've also seen console messages appearing out-of-order.