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:
Let’s take a look at these improvements to the F12 tools.
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
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.
With this feature now in F12, there are two key things you will see when you debug
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.
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.
As with Just-My-Code, we will go into more depth on source maps in a follow-on blog post.
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:
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.
The types view that you see above, shows the list of objects and a gutter indicator of where potential issues may reside.
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.
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.
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.
— Andy Sterland, Program Manager, F12 Tools
— Jonathan Carter, Program Manager, F12 Tools
— Simon Calvert, Lead Program Manager, F12 Tools