For several releases, Internet Explorer has had diagnostic tools that help developers debug visual issues, find JavaScript bugs, and profile Web sites. These tools have shipped both in the browser as the F12 Developer Tools as well as in Visual Studio. In the interest of making the modern Web “just work” for everyone, today we’re announcing an open-source, experimental adapter for Internet Explorer that we’re developing to contribute to a wider and more diverse tooling ecosystem across browsers. Right now we’ve targeted the adapter at Internet Explorer 11, but we intend to update it to work with Project Spartan in a future release.
Internet Explorer already supports WebDriver, which gives test frameworks a standard mechanism to automate the browser, reducing the cost to developers to add a new browser to their test matrix. In the same spirit, we want to enable third party tools to target IE like any other browser. The IE Diagnostics Adapter makes this possible by providing a bridge that allows IE to speak the Chrome remote debugging protocol. This protocol allows 3rd party tools to debug, diagnose, and profile Chrome. While not a standard, it is used by many popular developer tools, including products like Adobe’s Brackets. There’s also a community driven initiative, Kenneth Auchenberg’s RemoteDebug, that seeks to make the protocol common across more browsers – there are already bridges for Firefox and Safari on iOS.
Today our adapter only supports a limited subset of the API surface. You can attach the Chrome Dev Tools and get basic script debugging by running IE, starting the proxy, and browsing to http://localhost:9222/ from Chrome, as pictured below.
The adapter is still in active development, and you can check in on our progress on GitHub. We’ve open sourced it under the MIT license, so feel free to take a look and pitch in!
This adapter is an experiment for us, and we’re sharing it early and openly. We’re especially interested in getting feedback from tool vendors out there who are currently using the Chrome remote debug protocol. Part of being an experiment means that we don’t have a grand vision or a roadmap for the next 5 years. What we do know is that we want to make developing web sites for IE and Project Spartan as easy and enjoyable as possible. That means improving the tools we ship and also enabling others to build great tools that can target IE and Project Spartan.
More information and demos will be coming soon at the project’s GitHub repository, and we encourage you to check back there periodically for updates – we look forward to your feedback and contributions on GitHub and @IEDevChat on Twitter!
– Andy Sterland, Program Manager, Client Platform Tools