Debugging and Tuning Web Sites and Apps with F12 Developer Tools in IE11

Internet Explorer 11 on Windows 8.1 and Windows 7 comes with a completely redesigned and enhanced suite of in-browser developer tools that help developers build, diagnose, and optimize modern Web sites and apps across multiple devices. The new tools, which we call F12 for short, enable Web developers to work quickly and efficiently.

The Visual Studio and IE teams have worked together to build F12 with a core principle of helping you get from problem to solution quickly with actionable data. The new F12 enables you to deliver fast and fluid Web experiences with tools for diagnosing and fixing performance issues and tools that give you deeper insight into how IE is laying out and rendering your app. F12 supports the fast, iterative workflow used by modern Web developers.

A Comprehensive Toolset

The new F12 helps developers get from problem to solution quickly. Some of the biggest new capabilities include:

  • UI responsiveness and memory profiling tools to help you build fast and fluid Web apps
  • Live DOM explorer and CSS inspection tools that update with your page so you can iteratively explore how dynamic content is affecting layout or styles
  • JavaScript debugging that starts quickly without a page refresh so you can get to work more quickly

As you use F12, you’ll notice many other enhancements that will help deliver a fast, iterative workflow:

  • Quick entry into the tools through an “inspect element” right-click menu item
  • An experience that you can drive from the keyboard
  • Rich copying of elements and items from the tools, so you can paste into the editor of your choice without reformatting

Most important, the tools now show the most accurate and comprehensive information, from @media rules and !important in the DOM Explorer, to per-element layout costs on the UI responsiveness profiler. The tools also provide directly actionable data; for example, the memory profiler identifies all DOM nodes that are alive but not referenced from the markup or render tree.

The new F12 shares many of these experiences with Visual Studio so that developers get a consistent experience across the continuum of Microsoft’s Web development tools and platforms.

Let’s take a quick look at some of these tools in action.

Profiling an App with the UI Responsiveness Tool

The UI responsiveness tool helps you understand where CPU time is spent, so your app can achieve its greatest performance potential. The tool gives you the necessary insight into the inner workings of IE by providing you with a timeline visualization of HTML, CSS and JavaScript execution, along with important side effects such as layout and garbage collection. At a glance you can see exactly how responsive your app is as well as how fluidly it is rendering. This enables you to identify the specific source of any bottlenecks, which enables you to make more informed optimizations.

F12 UI Responsiveness Tool - Internet Explorer 11

Profiling a Web site

Understanding an App’s Memory Consumption with the Memory Profiler

The memory tool helps you avoid memory leaks or excessive memory use. Building Web apps that consumers keep running all day or complex interactive apps often means you have to pay more attention to memory usage in your app.

Although JavaScript is a garbage collected environment, apps commonly consume more memory simply because references to objects weren’t released and can’t be freed. The memory tool helps find those problems by giving you information on every object in the page, whether it’s in JavaScript or in the DOM. With this information, for example, you can see how much memory an <img> is holding on to and which objects are keeping it alive. Best of all, you can diff between two snapshots and see what has changed, so you can figure out why your app is using more memory and fix it.

F12 Memory Tool - Internet Explorer 11

A heap snapshot showing disconnected DOM elements

Getting Immediate Insight to an App’s Performance with the Performance Dashboard

To help you quickly identify performance problems on your running page, IE11 has an on-page widget called the performance dashboard that can be accessed through Ctrl+Shift+U or through the Tools (Alt+T) menu option. It draws in IE and provides live statistics for key performance metrics such as paint time, memory, frames-per-second (FPS) and CPU utilization. The performance dashboard does not require F12, and can be used in the immersive browser too.

With the performance dashboard, you can quickly identify page interactions that cause frame rate drops or high CPU utilization. You can then switch into the F12 tools to reproduce the issue and find the solution.

F12 Tools - Performance Dashboard - Internet Explorer 11
Paint Time Performance Dashboard - Internet Explorer 11

Inspecting Elements and Modifying Layout and Styles with the DOM Explorer

The DOM Explorer simplifies the interactive process of tuning your @media queries and your CSS rules and their properties, so that your app’s UI is perfect and responsive across multiple devices. You can quickly start in the Web page by right-clicking and inspecting an element, which launches F12 with that element selected in the DOM Explorer with the live DOM and applied CSS rules displayed. The DOM and CSS you see is live, so you can understand how IE is interpreting your markup, your styles, and CSS rules specificity. As you interact with the page or edit it through the DOM Explorer, your changes are reflected immediately.

F12 DOM Explorer - Internet Explorer 11

Inspecting Mark-up and Styles

As you make CSS changes, the DOM Explorer makes it easy to get the right property or property value with IntelliSense. You can easily see which properties are in error or unrecognized and then copy the rule to apply back to your source.

Debugging JavaScript with the Debugger and Console

The new JavaScript debugger gives you the tools to locate and fix error-prone code quickly. The JavaScript debugger can open and view multiple files even if your library script was minified, set breakpoints and trace-points, inspect JavaScript objects, values, scope chains;, and see stack traces. When you start F12, the JavaScript debugger starts immediately, so you can get right to work

You will likely want to interact with your Web site as you are debugging. To do that, the console is a key tool. You can access the console at all times, making use of its interactive environment with IntelliSense and object visualizers galore. The console also provides a range of specific APIs that enable you to log output, understand the amount of time spent in specific code, or provide object visualizers when you need to inspect your JavaScript objects deeply.


This post just scratches the surface of what’s new in F12. You can find a full list of new functionality available to developers in the IE11 “What’s new in F12 Tools” and in the IE11 “Preview Developer Guide.” You can also learn more with the IE Test Drive, “F12 Adventure.”

Please install the Windows 8.1 Preview from the Windows Store and try IE11, or try the IE11 Developer Preview for Windows 7.

We look forward to your feedback and engaging with the developer community. Please share your suggestions either through the IE11 Send Feedback tool or on Connect.

— PJ Hough
Vice President, Visual Studio

Comments (54)
  1. Mitch 74 says:

    Why do you insist on splitting properties with shortened notations into so many? Take margins for example, why don't you display "margin:0 auto" instead of "margin-left: auto;margin-right:auto"? It gets even more ridiculous with borders! Each side takes from one to 3 lines, instead of having everything on a single line… How to Waste Screen Real-Estate!

  2. Before IE11 is released can you PLEASE ensure all the glaring bugs are fixed from IE10?? I've catalogued the ones I've experienced here:…/c8d79e2b-8e6e-4734-bed2-7dbc4369175c


  3. Yannick says:

    The new F12 is a serious improvement. The only thing I hate about it is that UAC needs permission to open it, I hope that will be gone in the final? However, now only the option screen with a redesign and I'm happy.

  4. Jennifer Yu [MSFT] says:

    @ Mitch 74:

    When a shorthand property has been specified, F12 in IE11 displays just the shorthand property/value with an option to expand to its constituent properties. When a longhand property has been specified, F12 will display the longhand property/value. If you're still experiencing problems with shorthands in IE11, please provide us with repro steps so we can investigate it. Thanks!

  5. Jeff LoBello says:

    I miss the old Browser & Document Mode menus from the old F12 developer tools.  There doesn't appear to be a direct replacement in the new dev tools.  Please consider bringing them back.  The are helpful when debugging old IE sites.

  6. Greg Pakes says:

    @JeffLoBello +1

  7. Rob^_^ says:

    Use the "Break on all exceptions" setting in the debug console to solve hard to diagnose handled exceptions in third party modules like jQuery.


  8. L. says:

    First, your new debugging tools are too slow.  Please bring back a fast launch.

    The UI is not as intuitive as the old one.  Shallow menus are more discoverable.  One example is that I did not find a way to edit (add rules to) external CSS files.

    +1 for bringing back browser and document modes.  Sure it's not perfect.  (Nothing short of a dedicated VM is, because of fonts, network stack and such, and you got enough complaints to understand how much of a pain VM are).  Even with it's limitations, browser and documents modes was a useful feature for quick tests.

    Finally, I dislike how the UI looks.  Not everyone like this flat "Modern" appearance.  Please make it mode desktop-like.

  9. EdC says:

    There needs to be a right-click "Inspect Element" context menu like Chrome or I'm not even looking at IE11 for development purposes. It takes two steps to view an element in the DOM in Chrome vs. 4 in IE. When you are repeating this operation a few hundred times a week, it adds up and it gets in the way.


    Right-Click > Inspect Element


    Remove hand from mouse > F12 > Click the pointer icon > Click the element

  10. Brian LePore says:

    As mentioned by others, the lack of browser/document mode toggles is very unfortunate. Yes, I understand that VMs are very useful, They're great for a final run through. But the old version was far more helpful. I'm aware that it is still sort of there if the site is not set to "Edge", but it would be remarkably helpful if we could still access IE7-10 even if it's set to Edge.

  11. Brian LePore says:


    I'm on IE11 and they have a right-click -> Inspect Element option. It's right under "View Source". Didn't need to open the F12 tools.

  12. EdC says:


    Gus Perez also confirmed this on twitter (@gusper). So now I'm excited to see the improvements!

  13. Sven says:

    I have a question regarding document modes.  It states the HTML5 doctype — <!DOCTYPE html> — forces edge mode.…/bg182625%28v=vs.85%29.aspx

    Is this always the case?  Does it overrule the Compatibility View Settings window (the 'display all websites in Compatibility View' and 'display intranet sites in Compatibility View' settings)?

    (I'm hoping the answer is 'yes'!)

    Thank you for your time.

  14. SiSL says:

    It is indeed so slow @ Win8.1… Can barely open it. Barely move mouse around menus… Not to mention about Browser and document modes

  15. The Deeds says:

    @IE team,

    Thank you for the initiative of overhauling F12 developer tooling. But we are expecting few improvement in the existing features by final release.

    Please do not exercise the same behavior with the developers of your ecosystem who are giving you feedback…. all the below feedback items, pertaining to F12DT, are closed with some convoluted reason:…/791981…/791982…/792543

    I wonder why didn't you guys did it right in first place? Firebug for Firefox and Chrome dev tools are certainly not new to anyone in web development and they are great source of inspiration… Do you expect us to wait for IE12 or 13 to resolve these issues (which would probably not supported on Windows 7)?

    @Program manager – F12DT team, please do not ignore our feedback and please complete the features which we all are profoundly wanting. Its not just about YOU and YOUR definition of good enough, its what we — the developer — need. Filter the related bug reports on connect and have a little survey if you really care!

    This is very painful to see you shooting your own foot. Please help us help you to make our ecosystem better!

    Sincerely yours.

  16. Colourful says:

    Please bring back colour picker tool. Also provide colour picker and colour selector (like in VS2013) in CSS editor.

  17. Christian Stockwell [MSFT] says:

    @The Deeds: Let me follow up with the team on those three bugs. All three look like interesting issues for us to dig into. We're working to improve how we manage our Connect bugs and I'd like to take these three bugs back to the team to understand what we can do better.

    In particular, one thing that we want to be more transparent about are bugs that we think are "By Design" for a specific release vs. inherently "By Design". In the former case, "By Design" really means "out of scope for what we feel we can safely fix this release", whereas in the latter case "By Design" means that we think our current behavior is intentional "forever". Right now, those two resolutions are pretty hard to distinguish for a lot of bugs on Connect. We're also working to change our process to stop closing bugs for a given release when we'd like the bug active in future releases. We're still working through the details and a few exceptions may still slip through. I know you open a lot of bugs in Connect, so please continue to let us know if you see questionable resolutions.

    For those three specific bugs, 791981 looks like an example of "out of scope for this release". We've rebuilt the developer tools from the ground up in IE11, and the team's really focused on finishing those features that we decided to build in this release and improve the stability/performance of the tools. It sounds like it's a really good feature requests and I'll work with the team to reactivate it so that we have it on our radar once we finish IE11.

    I have to go do some research regarding 791982. I can definitely see the bug in our public Preview build, but on our newer internal builds it actually looks fixed! I'll follow up with the team to see where we went awry, but hopefully it's good to know that we're listening to your feedback–even when we don't quite do a good enough job letting you know we're listening.

    I'm going to follow up on 792543. As with 791981 that bug should have been left active either to fix in this release or to consider in a release after IE11. Behind the scenes, I can see that we have a flaw in our new process and this bug slipped through the cracks. I'm going to follow up to plug that hole and ensure that other F12 bugs don't accidentally get resolved "External".

    Thanks again for sticking with us and taking the time to file these bugs. I particularly appreciate your follow up to keep us accountable for doing a great job.

  18. Unstable Not Friendly says:

    Good to finally see improvements attempted but every time I use the dev tools I crash the entire IE process. You need to put some serious effort into fixing bugs and making these stable. Also the new tools are not very logical. Not that your last tools were logical but Chrome and Firefox does better job of logically representing my code and IE is just weird. I tried hard to like the new tools but tough.

  19. Christian Stockwell [MSFT] says:


    <!DOCTYPE html> alone won't guarantee edge mode. For example, if you have a site on the Intranet and you have the option to "display Intranet sites in CV" option checked you'll still end up in legacy modes. You can add the X-UA-Compatible on the page or send a server header to force edge mode even in those cases.

    In IE11 we removed the "Display all websites in Compatibility View" option entirely.

  20. Rob says:

    Developing for IE is like adjusting rabbit ear antennas for a TV.

  21. Stephan says:

    @Richa Prasad [MSFT] – do you have the latest "security" patch applied to IE (the one with the KB that ends in "71")?

    This patch massively broke legit, valid behavior and has been the bane of Web Developers everywhere that had legitimate in-viewport X,Y coordinate tracking.  (Anyone that got wind of this bug early DID NOT APPLY the patch to ensure that sites did not break… and turned off AutoUpdates until Microsoft releases a patch for the patch)

    That said my box is a Windows 7, 64 bit 8 GB Intel based laptop with the latest drivers etc.

    IE11's dev tools constantly crash, are ridiculously slow, the final panel doesn't load properly (everything is magenta… it just plain fails to render)

    No plugins installed and this breaks on pretty much any site I load from internal web apps to Google, to the IE blog.

    I'd love to give you more info but seriously it was so bad that I'm uninstalling it right now – totally unusable – it should have been flagged as an Alpha release if it wasn't ready yet.

    Attempting to use the F12 tools in IE11 on Windows 7 is just a complete waste of time.

    PS Try fixing the patch you guys broke first, then fix the textarea usability regression bug that you guys introduced in IE10 and still haven't fixed… then release a Beta quality IE11 for us to test!

    Oh and tell whoever controls this blog to fix the dam* comment form! seriously WT*?! is there no one at microsoft that actually DOES web design and knows how this stuff works?  ASP Postbacks are a TOTAL EPIC FAIL! DO NOT USE THEM  IF YOU DO NOT KNOW HOW TO GET AROUND THE BUGS!

  22. @Stephan:

    1. We've definitely heard the feedback about KB2846071 and are investigating.

    2. The magenta issue in the dev tools is a timing issue that appears to happen on some machines and not on others. We're already testing a fix in our internal builds. Thanks for letting us know!

    3. If you have specific steps that consistently lead to a crash in the dev tools, please file a bug on Connect so that we can investigate.

    4. Can you share a little more detail about the TextArea bug? A link to a Connect bug would help me investigate further.

    5. I hear you. Several of us are pushing very hard to get this fixed. I've lost several comments myself and it's very annoying.

  23. pmbAustin says:

    @Stephan, just log in and your comment form "bug" won't be an issue.  It takes 2 seconds to get a Microsoft Account (everyone has an Apple ID right?  And nobody bitches about THAT!  Hell, use your same AppleID as your Microsoft Account!), and two seconds to log in, and then you're logged in forever, and you'll never experience the "bug" again.

    People still complaining about this when there is a TRIVIAL work-around, are really annoying.

  24. Evan says:

    @Christian Stockwell [MSFT] & @Stephan

    1.) Yes! glad someone is looking into this!

    2.) I get the magenta too again glad it is being looked at

    3.) [startDiatribe] I'm not sure if you are new here Christian but this has been a long running contention between IE Blog readers/developers and Microsoft.  To put it bluntly – Connect is the worst bug tracking system we have ever used.  We've seen our reports get filed, ignored, then closed as "as designed" enough times that we are not going to play "The boy that cried wolf" anymore.  The vast majority of readers/developers have vowed never to return to Connect again until Microsoft makes a commitment to get a new system, NOT close/remove bugs just because they don't make it into a release, and to actually look at the reports, update them, and give serious ETAs on them making a version or not.  All test cases must be public (unless security related) so fellow developers can test/confirm bugs etc. TL;DR No serious reader of this blog will ever file a report in Connect again until there is an apology for the way we were treated previously and a promise to fix all the above issues.[/endDiatribe]

    4.) The Textarea bug from IE10+ is the fact that the cursor (caret) placement does not always go to the end of a line of text when the user clicks in the whitespace beyond the end of a line but in fact puts the focus at the beginning of the next line. Reported here back in March!…/bug-571-ie-10-textarea-focus-is-broken.html

    5.) I'm glad someone is pushing to get this fixed! Its only been broken for over 5 years now and the fix is a 1 liner. Just replace it with [input type="submit" value="Post"/]  (swap the brackets of course) and watch the magic happen! 100% successful form submission by cutting the broken ASP callback stuff completely out of the picture.  In addition on the backend the validation logic is severely flawed.  There is a post-timeout whereby if a comment is made and submitted 15min? after the page loaded the comment is dumped assuming it is spam.  This is silly considering it can take at least 10-30min to read the post and related comments before deciding to add your own.  It also blocks posts based on the quantity of links contained within.  This is a tough metric to use when most of the posts are "hey you broke this on this site: U-R-L" or you don't follow spec X at U-R-L. There's also a token set per IE Blog page loaded which means if you open another blog link in another tab (e.g open the last 3 posts into tabs) if you do not submit your comment on the last-loaded tab – then it fails a broken-security-check that invalidates your post. This is the problem with using blog software that was developed for IE5/IE6 when IE didn't have tabs.  It tried to add security through the "user will never run 2 or more browser windows of our application at once" philosophy which hasn't been applicable for lets see… about 8-10 years!

  25. Evan says:

    And a personal note to @pmbAustin

    No one cares how easy it is or isn't to register a Microsoft account to post a comment. THAT'S NOT THE POINT! If the form is going to be open (which it most certainly should!) then that has to work too. Not some of the time. Not most of the time. All of the time! This is basic 101 HTML form technology we are talking about.  Only Microsoft (and the Community Server Blogware) software has this issue. Every other site doesn't have this issue because it is a SOLVED PROBLEM!  Sadly someone at Microsoft (in the legacy ASP dev team) tried to circumvent the default behavior (and someone at Community Server decided to implement it without proper testing) – fail.

    More importantly if you know that this site is broken – help Microsoft by being the squeaky wheel to get this bug fixed – not trying to sweep it under the covers as a non-issue. 1,000's of comments have been lost because users had no idea that Microsoft's flagship blog comment form was designed over a decade ago by a programmer that didn't understand the technology on a platform that didn't understand how the web was being used.

  26. Arieta says:

    Huh, I just noticed that Ctrl+Q was removed in IE11 – can we have that back?

    Same for the Document Mode switcher in the developer toolbar, to check IE7-8-9 behaviour. That thing was really useful.

  27. Arieta says:

    On another note, I've noticed that add-ons now load in every frame process, which significantly raises compatibility with older add-ons. So it is no longer necessary to force TabProcGrowth = 0 to get some essential add-ons to work.

    This is a VERY welcome change and I really hope that it will stay that way into the final release!

  28. Blaine says:

    For the messed up popup windows in IE here's the registry key you need to reset because Microsoft's Developers and Q.A. are not paying attention.

    Registry Key:

    ComputerHKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainWindow Title

    Change the value from:

    "Internet Explorer, enhanced for Bing and MSN"


    "Internet Explorer"


    "Internet Explorer 11 Alpha Preview – watch me crash!"

  29. Arieta says:

    The developer tools seem to cause a system wide problem in the context menu. Whenever they crash (which happens often), they cause some problem in whatever function that is used to open the right click context menus in Windows 7. Once this bug gets active, a right click context menu will not fade in properly, it displays only at a low opacity. When any selection is made on any context menu afterwards with the mouse, the selected context menu becomes permanently etched into the foreground. The only way for it to get removed is to do a change that causes a display refresh – such as any application going fullscreen and then exiting, disabling/enabling DWM, and so on. Then the bug can trigger again once you use a context menu again.

    However pressing the context menu keyboard key will not trigger this oddly enough.

    This effect stays there until reboot.

    I'm inclined to think that this is a videocard driver bug though (using a Radeon 6950 with Catalyst 13.4).

  30. @Even:

    3. As I mentioned in my earlier reply to TheDees, we're working to improve Connect (the site) and our process for managing Connect bugs. As I mentioned above, one change we're already working through is to make Connect IE version-agnostic, so if you file a bug we will leave it active if we want to fix it but just can't fit it into the current release. We're still working through the details, so please let me know of cases where you see bugs gets closed when they should not.

    4. Thanks for sharing that link, that's what I thought you were seeing. Have you tried that repro on IE11? That was one of the cases that we tried to fix in this release, and in my repro case (…/textarea.htm) I do see that IE11 now behaves correctly even though IE10 did not. It would be great to know if you're still seeing something that we haven't addressed in IE11.

    5. Thanks for the detailed summary. We'll continue pushing for a fix and hopefully we'll have something positive to report back 🙂

  31. Anonymous says:

    @Christian Stockwell (MSFT)

    On Connect, what is the difference between a bug that is "closed by design" as opposed to one that has been closed as "postponed"? Do you randomly assign these labels? Because, currently, they make no sense!

    When a new version of IE comes out, we would have to re-file existing bugs anyway. So, marking something as "postponed", makes no sense.

    Similarly, many bugs that are now marked as "closed by design" are, I hope, issues that you would consider for a future release. It does not make sense to close them for ever. So, what is the purpose of the "closed by design" label?

    I think that when you see a bug you don't like you just click a close choice at random, while murmuring to yourselves: "Who cares? They will re-file it next time".

    Well, we are not going to! We are not your paid secretaries who have the time and energy to re-visit, re-test, re-file, re-try and do all the re-s. We are not Microsoft servants.

    Please do the job yourselves! Go back and look at the Connect bugs for IE 8, IE 9, IE 10 and IE 11, figure out which ones should still be active and consolidate in a single list. Mozilla, Google and others have been running an open bug database for years. Why can't you? Please explain. I want to know what is so hard about it.

    Even the MSDN feedback system is broken. When you provide feedback on a page it only has three choices: "Information is not accurate", "needs more information" and "More code examples". Well, firstly not all pages need code examples, so the third option is out of place. Plus, so many other choices like "information is confusing", "spelling or grammatical error", etc. are missing. Look at Google help sites and their feedback choices for example. Complete and to the point. MSDN is broken after 15 years. And the documentation sounds as if it is written by a robot. It is not conversational in style.

    So, where is an open and good bug database? Where can I give feedback as a user without having to go through hoops? Why is the developer documentation still so bad like in Chrome?

    What's wrong with you guys? What's so difficult? Company bureaucracy?

    Open source projects can set up a bug database within a day. They can set up a functioning blog commenting system again in one day.

  32. Anonymous says:

    Oops! I meant to say:

    So, where is an open and good bug database? Where can I give feedback as a user without having to go through hoops like in Chrome?

  33. BlindProgrammer says:

    @Christian Stockwell (MSFT)

    I am blind and use a screen reader. It's called Jaws (version 14). I can't use the new developer tools. I can't read the code I am debugging. Please please help me. Chrome's developer tools are inaccessible. Firebug is not fully usable too with assistive aids. IE was using standard Win32 controls and so I could use its developer tools to do my job. I still need to continue doing my job. Do not release IE 11 without fixing the accessibility of your developer tools. Please!

  34. Sunil says:

    Too Bad , I can not change the compatibility mode for the websites , Please do not take away  1) Color Picker 2) option to change the Compatibility

  35. Jason says:

    @Christian Stockwell [MSFT] – thanks for fixing *most* of the bugs with the textarea focus from IE10 (PS is this fix going to be back ported?)

    However the bug is not completely fixed.  Try typing this into your sample page swapping [[EMPTY]] for no character data.

    Then try to click into the *FIRST* empty line. You can't because the bug is still there trying to focus the next line.

    Sample test text (between the quotes):


    First Line

    Second Line



    Fifth Line

    Sixth Line


    As for your candid response about fixing Connect so that bugs never go away that is good to hear but note that test cases must also be public so that fellow users can confirm they exist/don't exist.

    I'm one of the many developers that have given up on Connect and have no plans to return.  However once everything has been fixed up if there is a blog post about the improvements and a sincere apology for the way we were treated in the past I will be more than happy to return.

  36. @Jason: Thanks for the follow up test case. I haven't been able to find the specific bug that we fixed between the public preview and our current internal builds, but in my testing I can reproduce the issue you're describing on the Windows 8.1 Preview and cannot on our more recent internal builds. It looks like it's fixed 🙂

    I appreciate your frustration with Connect. I'm certainly sorry that we've fallen short of your expectation of Microsoft. We're interested in improving both Connect and our bug management process, but to do that we need your help. When possible, please continue to file bugs and keep us accountable when you think that we've resolved a bug incorrectly. Feedback from Connect users (like The Deeds' feedback above) has already helped us identify several places where we can tweak our process to make Connect a more effective tool.

  37. Martijn says:

    "Debugging and Tuning Web Sites"

    Really? You seriously believe debugging on IE11 is sensible?

    Two word: DOCUMENT MODES

    Really Microsoft, come on.

    D O C U M E N T   M O D E S ! !

    I expect them to be back in the next developer update, or I cannot take IE11 serious as a debugging tool. That, or make it possible to run multiple versions side-by-side. Do not force people to use a VM.

  38. james says:

    IE11 F12 menu bar?

  39. Stifu says:

    I may not be blind, but I'm still concerned about what BlindProgrammer has been reporting for a little while (see previous article comments for more details). So far, I haven't seen anyone from Microsoft address this. What's up?

  40. A frustrated developer says:

    STOP making browsers!

    You owe developers Billions of frustrated hours!

  41. @Stifu: I'm not an accessibility expert and don't have a site license to Jaws so I haven't commented. We've filed a bug for the F12 team to investigate and they're digging in.

  42. Stifu says:

    @Christian Stockwell [MSFT]: Cool, thanks.

  43. Greg says:

    @Christian Stockwell (MSFT) – I think you've missed the important issue here – WE ARE NOT GOING TO USE CONNECT (nor Start using Connect) until the system is fixed! We suffered through years with that lousy tool and the complete disregard for our contributions. You (Microsoft) failed us over and over again.

    We've had enough of being treated poorly and we've told you time and time again we will not return until there is an apology AND a fixed site.  Until you have both of those the hardcore developers and testers that gave you thousands of hours of bug reporting data in IE7, IE8, & IE9 will NEVER return!

    I'm not sure how we can make that any more clear to Microsoft.  You seriously burned bridges there with the community that will take serious effort and commitment to restore.  "we're working on fixing it" is good to hear but we ARE NOT TOUCHING it until you've announced that it is fixed and that you apologize for how we were treated in the past – it was incredibly unprofessional and showed just how little interest Microsoft had in engaging with the community.

    There's many reasons why developers all choose a non-IE browser as their default development browser – this is in the top 10!

  44. Sanket says:

    The best what Microsoft can do is get old browsers upgraded to at least IE9, IE11 is far away, a dream. IE8 and below are a barrier for the development of next gen apps. Still we have IE8, which contributes 5% of the internet traffic. So it makes no sense whatever awesome browsers you develop until you replace the old ones.

  45. Damiano says:

    I agree with @Sanket

    IE8 is the new wall as IE6 was

    Consider that now browsers are used as universal client for any kind of service also in the INTRANET

    We have hundred PC with XP because it is more than enough and due the business rules no internet browsing is admitted.

    No third-party browser is allowed, domain policies are VERY strict.

    So we still developing and maintainig the frontend application for IE8 untill the last single old PC will die and be replaced.

  46. Yuhong Bao says:

    @Christian Stockwell [MSFT]: Also I hope it will track if bugs are fixed in cumulative updates for older versions of IE.

  47. BlindProgrammer says:

    @Christian Stockwell (MSFT)

    Thanks for filing a bug with the team.

    You may try testing with the free NVDA screen reader if you don't have Jaws.

    It seems that in the debugger, even though the code is in a textarea, I can't get my screen reader's reading cursor to stay inside it. If I try using the system cursor, it seems that they use ARIA alerts to announce the current line every time you cursor, creating a horrible experience. You hear the word "alert" every time you move and if you move using cursor left/right you hear the whole line again (I know even know what happens if you move by word). Blank lines say only "alert". Please allow the screen reader to handle reading, don't feed it text using ARIA alert. I have my own reading settings in my screen reader (punctuation level, key + word echo) that I want respected.

    The context menu does not come up when you are in the code textarea and press the applications key. How would I set a breakpoint, copy, paste, etc?

    The keyboard flow is a mess. You have to press tab one hundred times to get anywhere. Previously, when win32 controls were used, tab would take you to each toolbar and then you would use the cursors to move within that particular toolbar. Now it's tab tab tab and tab again. Also, does f6 and shift+f6 work to take you from panel to panel? Is shift+tab programmed correctly?

    But the worse is that many controls read button button button. I can't hear a meaningful label.

    You replaced a win32 interface with 20 years of accessibility strengths behind it, with a sudo HTML5-based UI that is not accessible. Don't you know that HTML5 apps have a horrible accessibility record? The native rich text box has 20 years of accessibility work put into it. How do you expect textarea with some CSS magic to replace that? The win32 toolbars know how to handle tab, cursors, space, enter shift+all the above, home, end, etc. correctly, plus if you put pop-up menus inside them, they are by default accessible. Does sudo HTML5 UI know how to do that? I doubt it.

  48. @BlindProgrammer: Thank you for the detailed feedback–I'm going to make sure that it gets to the tools team.

  49. Alfonso says:


    As other fellows have stated, you (Microsoft) are the ones that have managed to drive us away from your Connect site, so you have to review carefully all the problems that we have stated if you want to ever trust you again.

    Testing, debugging to find a simplified testcase, writing everything down takes time. You can't just say that you will try to review your procedures for IE12, you should review them right now.

    Put someone tasked to look after every bug that was reported for IE9 and IE10 and it was closed as "by design". Every one of them.

    Now check if that bug exists in IE11, if the problem still exits then it's time for someone with more knowledge to look at the report and decide if it's something that you never plan to change, if it was a bad report (someone asking to change something that it's a security problem), or if it's something that would align the behavior of IE with other browsers and the web development.

    Then for every one of those valid reports, re-open them or create a new list stating known issues with IE that you don't plan to change in IE11 (due to lack of time, too complex at this point, etc…) just keep that list alive, show us that all the issues that were reported have not been deleted and forgotten.

    I tried to give IE11 a chance last week, so I downloaded it because I was interested in the new features related to inserting images from the clipboard. Obviously I quickly found that despite your claims about compatibility my current code didn't work so I filed a bug report stating the problem:…/clipboarddata-should-be-a-member-of-the-event-and-not-of-window

    Unfortunately the almighty "Microsoft" closed it after 30 minutes, and when I woke up next morning I added the requested url so you could test and verify that IE11 doesn't match the behavior of Firefox and Chrome, so any existing code that tries to pick files from the clipboard won't work in IE11 and the users will wonder why you claim that you have added this feature when in fact it doesn't work as expected.

    There are further comments that I would love to do so you could enhance it and make IE11 the best browser with regards to handling clipboard operations, but you can bet that I won't be wasting my time writing them if you're gonna throw them to the bin that way.

    It's in your hands.

    PS: (I was smart and I remembered to copy everything that I wrote here before pressing "Post" or I would be really angry)

  50. @Alfonso: Thanks for the bug report, I'm following up on that "By Design". With the html file you provided I can see that we have the clipboarddata on the window object rather than the event object. I'll get it sorted out.

    Regarding your first few points: Several of us are working to improve our Connect site, and we're starting by trying to address some of the biggest issues with Connect first–eliminating the sign-in requirement, keeping bugs alive even if we can't fix them in the current release, and other top pain points. Whenever possible we're also working to make sure that great bugs get opened/reopened, but we're also trying to balance that time against the time we spend making IE11 great.

    I know that it's asking a lot, but I do appreciate your help and encourage you to keeping filing bugs on Connect. When we fall short of your expectation, let us know! We aspire to perfection, but until we get there all I can promise is that we care and want to improve.

  51. Alfonso says:


    Thank you.

    For me, signing in for Connect is not a problem, I don't know who has thought that the requirement for signing in is a problem because I think that any other bug tracker requires the user to have an account or it becomes impossible to request back any extra info to the reporter, get notified about changes, etc…

    Any real developer that wants to see a bug fixed will gladly sign in as long as he feels that you're treating the reports correctly. And also it should help you notice if a person is usually reporting garbage or he has been working for years providing testcases and the such.

    As I said, as a simple solution you could just publish a page with a listing of bug reports that you acknowledge that should be kept alive for future versions of IE but that won't be targeted for the current version and that would be great. No misunderstandings, no big changes to the bug tracker, publishing such a list and adding there any previous and new report that you want to close as not something that will be done for IE11 is a "simple task" that doesn't require any investment, nor even a commitment to fix those issues for IE12, it would be a first simple step to make people return back .


  52. Jake says:

    @Alfonso, @Christian I think the issue with signing into Connect is that it used to be required to view a bug.  (I'm presuming that this bug has been fixed!) however it is CRITICAL that viewing bugs not require a login so that when bugs are posted on Twitter & Facebook and shared on this blog (and other blogs) readers can quickly check them out AND run the test cases to verify if the bug exists for themselves (or maybe even confirm that it isn't widespread… maybe only IE11 preview is affected.. maybe IE10 and up? (e.g the Textarea bugs).

    If connect isn't open to this level of read-only view access then you know what your job is to fix before the weekend ASAP!

  53. Alfonso says:


    I've checked right now and I can see the bug reports in…/Feedback including attached files, so if people are still upset about that problem, the very least that they should do is test and check how Microsoft has already fixed it

  54. Kanchan says:

    F12 Developer tool is really handy for UI development. But, any JavaScript based validation can be easily bypass using browsers like IE11 using its debugging features. Moreover if authorization is implemented for any app through JavaScript, that can be also hacked by putting different role, value through JavaScript or CSS.

    Do we have any path or solution which will disable the F12 developer tool and that will not allow user to enable again.

Comments are closed.

Skip to main content