Debugging in IE10 on Windows 8

Emulating the “non-Desktop Experience” in the Desktop Experience

The new full-screen “fast and fluid” experience of IE10 on Windows 8 offers many improvements over Internet Explorer 10 on the Desktop (ranging from UX to Security), but one thing it lacks is the F12 Developer Tools, used by web developers to debug web pages.

While you can use Visual Studio to debug pages, sometimes, debugging with the lightweight F12 Developer Tools on the Desktop can be simpler. However, what if your bug doesn’t repro in the Desktop experience?

In many cases, you can emulate the non-Desktop experience on the Desktop by making simple configuration changes:

  1. Enable Enhanced Protected Mode by clicking Tools > Internet Options > Advanced and ticking the Enhanced Protected Mode checkbox in the Security section near the bottom of the list.
  2. Enable ActiveX Filtering (Tools > ActiveX Filtering)
  3. Press F11 to put the IE Window in full-screen mode

With these configuration changes in place, you can continue to use the F12 Developer Tools while emulating the non-Desktop experience.

Note that one limit to the quality of the emulation is that the ActiveX Filtering feature will filter out Adobe Flash content from all sites. Such content is permitted in the non-Desktop experience only when your site is on the CV List or the DebugDomain registry key is set.

Debugging Local Content

Web Developers often test pages or sites on their local systems before it is deployed to production. In some cases, there are side-effects to debugging local content that developers should be aware of.

  1. When debugging against a dotless hostname (e.g. http://localhost) the content will typically be in the Local Intranet zone. By default, this means:
    • Security settings (e.g. File download, ActiveX behavior, cookie controls, popup blocker) will be different.
    • The site will run outside of Protected Mode or Enhanced Protected Mode, which means that extensions will run with fewer restrictions and cookies and other storage will be “partitioned” from Internet Zone storage.
    • If the hostname is merely dotless and isn’t localhost, the page will run in Compatibility View by default
  2. When debugging against or any other hostname which points to the local computer but is not mapped to the Intranet zone:
    • Requests from "Windows 8 Apps” and IE running in Enhanced Protected will be blocked due to AppContainer Network Isolation
  3. When debugging content loaded from a file:// URL, other restrictions include:
    • The content will typically be subject to the Local Machine Lockdown
    • The IE8/IE9 XMLHTTPRequest object is not able to send requests (fixed in IE10)
    • The IE8+ XDomainRequest object is not able to send requests
    • Storage with domain-based security policy (e.g., HTML5 Storage, IndexedDB) is disabled
    • If the content runs inside Enhanced Protected Mode, subdownloads may fail if they lack a Mark-of-the-Web.

For scenario #1, you can disable the Local Intranet Zone by clicking Tools > Internet Options > Security > Local Intranet > Sites and unchecking all of the boxes. Of course, this will also mean that your content runs inside Enhanced Protected Mode, which can cause the problems listed in scenario #2.

To help address scenario #2, Fiddler4 includes a tool called the EnableLoopback Utility which can be used even when Fiddler isn’t running. It’s simply a graphical version of the CheckNetIsolation.exe command line tool which is used to exempt specific AppContainers from loopback restrictions.

If you’re having issues in scenario #3, you can consider using IIS Express or Fiddler’s AutoResponder tab to serve your local pages from a local web server.

I hope that this post is useful. If you encounter any other “gotchas” or have other tips for local debugging, please sound off in the comments below!


Comments (6)
  1. Rob.. says:

    also debug your web apps by running IE 10 desktop in noAddons mode or

    Internet Options>Advanced tab>uncheck "Enable third-party browser extensions"… close and restart IE for the changes to take affect.

    also check your Encoding settings and accessibility settings for a user Stylesheet, "Ignore font styles specified on web pages" and "Ignore font sizes specified on web pages"

    if comparing rendering in different web browsers ensure that they are all using the same default font family and size…

  2. Avi says:

    Hi Eric,

    Thanks for the information given.

    I am not able to find cookies folder for IE 10 on Windows 8. where is it or where are the cookies stored?

  3. EricLaw [MSFT] says:

    @Avi: Desktop IE's cookies haven't moved; hit Win+R and type shell:cookies to see the MediumIL cookies, and open the Low subfolder to see the Protected Mode cookies. Cookies for Internet Explorer when running in non-Desktop mode can be found under %USERPROFILE%AppDataLocalPackageswindows_ie_ac_001ACINetCookies although it remains unsupported to try to access the cookie files directly; use the WinINET enumeration APIs instead.

  4. Avi says:

    @Eric: Thank you for your prompt reply.

    I am not able to retreive the cookies using FindFirstUrlCache Entry on windows 8 IE 10.

    what can be the reason? It is working on windows 7 IE 9.

    What can be the reason. and which api will be useful in this case?

  5. Dave Porter says:

    The msdn forums page is a big ol' FAIL for me, can you please repost this to this IE forum and try to get any insight back to  My title of this post was to be "Two questions about "pure SVG document" in IE9."  I tell ya there are sure some usability flaws in making your way around MSDN.  Thank you Eric!!

    I am adapting a server-hosted XSLT-based SVG document generator, so that it works in IE9.  My project has always worked great in Firefox, but I am having a number of issues with IE9.  It is not feasible to re-host what I am doing so that it arrives at the browser as an HTML5 document, or SVG inline or embedded in XHTML.  There are a number of difficult / impossible issues for this latter approach that I can't solve yet remain browser-neutral.

    A. When a pure SVG document arrives at the browser, Javascript onload= events attached to SVG DOM elements seem to fire early (before the element is fully loaded or accessible).  In particular onload= attached to the root SVG element.  I'm having a bear of a time ensuring I can actually script access to contained elements and attributes.  Sometimes they are accessible, sometimes not, sometimes only part of the child elements are available.  Firefox has never had this problem.

    B. Is there a way to guarantee that the IE9 browser receiving the file is in the correct mode to render SVG.  In our company (I think?) the default install of IE is some kind of compatibility mode so that IE8-genre pages will load correctly.  There is a little gem of a meta tag you can supply via an XHTML document, in the <head> tag, saying "meta http-equiv='X-UA-Compatible' content='IE=9'/>" which forces the issue.  Inconveniently, there is no equivalent of that in a pure SVG document.  Can you suggest a way to ensure IE9 be configured to support pure SVG documents.

  6. PhistucK says:

    @Dave Porter –

    B. You can send an HTTP header instead of including a <meta>.

    X-UA-Compatible: IE=9

    Does that work?

    (Try adding it using Fiddler2 if you cannot do it using the server, just to see if it resolves your issue and maybe also the first issue)

Comments are closed.

Skip to main content