Category Archives: F12 Developer Tools

Auto Added by WPeMatico

Breaking on DOM Mutations in the Microsoft Edge DevTools

Editor’s note: This continues the series we began last week, highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.
As the web platform evolves, the line between web and application developers continues to blur. It’s common now for a web site to be more like a web app, with complex, single-page user interfaces built up by a combination of libraries and custom JavaScript code. This in turn has led to a web platform that requires more sophisticated tools to efficiently debug.
As we rely more and more on JavaScript to build up the DOM, and rely on tools that interact with and abstract away from us the nuances of DOMs across browsers, we lose the ability to easily know what caused a change to an interface node, especially if that change is unexpected. In EdgeHTML 16 (available with the Windows 10 Fall Creators Update), we’ve introduced the ability to break on mutations caused by any of the 450+ DOM APIs in the EdgeHTML platform and jump directly to the script that triggered the change.
For those who use Chrome DevTools, this will be a familiar and welcome addition to Edge debugging. It was our goal to implement and advance on a similar experience to make jumping between the two tools as seamless as possible. Read on for the changes you can expect in the Fall Creators Update (and can preview now via Windows Insider builds).
Breakpoint types
There are three breakpoint types:
Subtree modifications: when a node is added or removed from the subtree of the element on which the breakpoint is set
Node removal: when the node the breakpoint is set on is removed from the DOM tree
Attribute modifications: when an attribute of the node on which the breakpoint is set is modified
Setting and managing breakpoints
To set a breakpoint, right-click on a node in the DOM tree in the Elements tool. Under the DOM breakpoints item, you’ll see options to set and unset the supported breakpoint types.
Add new breakpoints by right-clicking a node in the DOM tree and selecting “DOM breakpoints.”
When you add a breakpoint, a red breakpoint indicator appears next to the node in the DOM tree. The breakpoint is also listed in the DOM breakpoints pane which exists in both the Elements and Debugger tools. You can disable and delete breakpoints by using the mouse to click the checkbox and delete icons, respectively. You can also right-click, or use the keyboard, on a breakpoint to invoke a context menu to apply the same actions:
Disable or delete breakpoints in the new DOM Breakpoints pane.
Triggering a breakpoint
A breakpoint is triggered whenever one of over 450+ DOM APIs are called by JavaScript. When the breakpoint triggers, you’ll jump to the Debugger tool with the file containing the triggering script opened and the line with the API call highlighted.
When a DOM API triggers a breakpoint, the Debugger tool will open with the API call highlighted.
In the Debugger tab, you’ll notice at the top of the call stack is an entry with the selector for the node the breakpoint was triggered on, and the type of breakpoint triggered.

Breakpoint persistence
We store breakpoints as part of your Edge DevTools settings and scope them to the URL of the page they’re set within. When you close and re-open Edge DevTools, or refresh the page, we’ll restore and attempt to automatically rebind the breakpoints to their respective DOM nodes. If we’re unable to automatically rebind them, we’ll indicate that they’re unbound in the UI with a warning icon on the breakpoint circle.
Breakpoints that cannot be rebound when the session is restored will show an alert icon in the Breakpoints pane.
You can use the context menus or shortcut icons in the DOM breakpoints panes to manually rebind any breakpoints we were unable to automatically rebind.
What’s next for DOM Breakpoints
We’re excited to launch this feature and hope to solve for as many developer scenarios as we can, but want to highlight a few gaps in the current implementation:
We don’t currently support rebinding breakpoints inside iframes. If you set a breakpoint in an iframe and close Edge DevTools or refresh the page, the breakpoint will be lost.
If your script encounters a synchronously-executed breakpoint before the DOM readyState is completed, you won’t be able to set a DOM breakpoint while the debugger is paused. You can typically remedy this situation by setting the defer or async script attributes.
For synchronous scripts, we trigger automatic rebinding of breakpoints when the window.onload event is called. In this case, we may miss binding breakpoints that would trigger during initial script-driven build-up of the DOM. For asynchronous scripts, we trigger a rebind attempt before the first script executes, so your breakpoints may rebind and trigger as desired.
We’re evaluating closing these gaps in future releases, as we continue to evaluate the prevalence of these scenarios. If you have feedback and find these unsupported areas to be blockers, please let us know!
Tell us what you think
We hope you enjoy this new addition and find it improves your productivity as you go about your developer workflows. If you find any bugs, please report them via the Feedback Hub. If you have questions or feature requests, don’t hesitate to leave a comment here, or reach out to us on UserVoice or Twitter.
— ­Brendyn Alexander, Senior Program Manager, Microsoft Edge DevTools

New and improved Event and CSS inspection for Microsoft Edge DevTools

Editor’s note: This is the first post in a series highlighting what’s new and improved in the Microsoft Edge DevTools with EdgeHTML 16.
EdgeHTML 16 is now rolling out to devices around the world as part of the Windows 10 Fall Creator’s Update—and with it, some great improvements to the Microsoft Edge DevTools.
In this post, we’ll walk through a slew of new updates to the Elements tab (formerly known as the DOM Explorer) with improvements to CSS at-rules, Event Listeners, Pseudo-Elements and the overall user experience.
CSS at-rules
In EdgeHTML 16, we’ve completely redesigned how at-rules appear in the Elements tab. Previously, usage of CSS at-rules were either missing or incorrectly displayed. The DevTools now show @supports, @media and @keyframes styles in separate sections within the Styles pane:

The new at-rules interface inspecting @keyframes on the CodePen example above
We also added a new pane for inspecting the rendered font of an element. In the Fonts pane, you can now see whether a font is served from the local machine or over the network and what, if any, fallback font face was used. If over the network, the DevTools will show the correlating @font-face rule:

You can now inspect the rendered font of an element in the Fonts pane.
Ancestor Event Listeners
The DevTools now allow you to inspect all event listeners on ancestor elements up to the current Window with the Ancestors option. You can also group event listeners by Element to see how the events will fire at each level of the element tree. This enables you to determine where a rogue event listener might be firing higher up the tree.

You can now inspect all event listeners on ancestor elements up to the current Window with the Acnestors option.
Ancestor Event Listeners can be grouped by Element or Event.
In the Styles pane, the DevTools now group styles by their respective pseudo-element, supporting ::before, ::after, ::first-letter, ::first-line and ::selection. This should make it easier to determine which style is winning the cascade.

Styles are now grouped by their respective psuedo-element.
User Experience
This release also includes some tweaks to the user experience of the DevTools to make it easier for developers who work in multiple browsers.
In particular, Layout pane has been removed and the box model is now at the top of the Computed pane, freeing up space for two new panes: Fonts and DOM breakpoints.

The box model is now at the top of the Computed pane.
Finally, to make it easier on developers who switch between multiple browsers, we’ve added two new ways to launch the DevTools: Ctrl+Shift+I and Ctrl+Shift+J. Ctrl+Shift+I will launch the DevTools just as the F12 keybinding does today. Ctrl+Shift+J will launch the DevTools (if not already open) and take you directly to the Console.
You can try out and file feedback for these new features starting with EdgeHTML 16, and find us on Twitter @EdgeDevTools to let us know what you think!
— Clay Martin, Program Manager, Microsoft Edge DevTools

Microsoft Edge Web Summit 2017 recordings are now available on Channel 9

Last week we welcomed hundreds of local developers and thousand of online viewers to our third annual Microsoft Edge Web Summit! Videos and slides from each session are now available to stream or download on Channel 9.
Learn about what’s new in EdgeHTML 16 in the keynote at Microsoft Edge Web Summit 2017.
Our sessions will bring you up to date on what’s in store for EdgeHTML 16, including learning how to use new and updated features like CSS Grid Layout, object-fit and object-position, WebVR, and the Web Payments API.

Learn about how to build faster websites with a fast and furious tour of web performance in the real world, and how to keep your development and testing on track with sonar, a new open-source, community-owned linting tool for the web. And make sense of the always-evolving web app landscape while blending the best of web and native with Progressive Web Apps.

Or go on a deep dive into the inner workings of the browser, to learn how we’re constantly rebuilding Microsoft Edge to be more secure, more accessible, and faster than ever, with every release we ship.

That’s just the beginning – there’s lots more to see on Channel 9, and we’ll have more to share about these topics and more in the coming weeks right here on the Microsoft Edge Dev Blog.
Thanks for joining us at Microsoft Edge Web Summit 2017 – we can’t wait to see you next year!
— Kyle Pflug, Senior Program Manager, Microsoft Edge